Description of problem: goa-daemon is running by default without any normalmeans of shutting it down aka turning it off Version-Release number of selected component (if applicable): gnome-online-accounts-3.20.3-1.fc24.x86_64 How reproducible: Upgrade to Fedora 24 Steps to Reproduce: 1. ps -ef 2. observe /usr/libexec/goa-daemon and /usr/libexec/goa-identity-service Expected results: No identity software running without my actual active consent. Additional info:
(In reply to udo from comment #0) > Expected results: > No identity software running without my actual active consent. Eh?
(In reply to Debarshi Ray from comment #1) > Eh? Are you too unaware of reality tha there are valid reasons not to use any 'social' media? If so and if not so: why are there no means to shut down the software implied here? Concluding NOTABUG without properly understanding means something else.
There is no systemd service we can mask. There is no config setting we can change to disable this software persistently. There is no choice at all. (as far as I am still aware)
Who designed these beautiful dependencies? # rpm -e gnome-online-accounts-3.20.5-1.fc24.x86_64 error: Failed dependencies: libgoa-1.0.so.0()(64bit) is needed by (installed) libgdata-0.17.5-2.fc24.x86_64 libgoa-1.0.so.0()(64bit) is needed by (installed) control-center-1:3.20.2-1.fc24.x86_64 libgoa-1.0.so.0()(64bit) is needed by (installed) evolution-data-server-3.20.6-1.fc24.x86_64 libgoa-backend-1.0.so.1()(64bit) is needed by (installed) control-center-1:3.20.2-1.fc24.x86_64 Who designed this without OFF switch? Who should not be designing any longer?
In general: One should be able to turn off processes on their own boxes. (i.e.: because they use CPU, memory, etc) When there are other reasons as described above the reasons to provide such an OFF method (as there is no human interaction method provided!) are GREAT.
Agreeing with what Udo says, users should be able to decide if they want to run goa-daemon or not. Sidenote: I just filed bug #1420678 as goa-daemon is consuming 1,5GB RAM on my system and I don't even use any service provided by it.
It is quite obvious that despite the documentation on various interfaces that the user interface has been totally forgotten here. Quality control thus is lacking. So please PLEASE enable the user to choose. Either by not starting this software or by removing the bogus RPM dependencies.
Choice is the ultimate requirement here.
(In reply to udo from comment #8) > Choice is the ultimate requirement here. http://www.islinuxaboutchoice.com/
Please do understand that people without the need for the accounts that your software 'helps' in some way do not have the need for your software (goa-etc). So please understand the need for the ability to not use the software, not install the software. Oneliners like at the link do not help.
There are some major misconceptions here. (In reply to udo from comment #0) > Description of problem: > goa-daemon is running by default without any normalmeans of shutting it down > aka turning it off > > [...] > > Expected results: > No identity software running without my actual active consent. There is a lot of code "running" on your computer that is neither used by you, nor is there any "normal means of shutting it down". The Linux kernel has all sorts of things that you probably don't use, but is still consuming memory. Your web browser, your window manager, your display server all have some code that's never used by you, but they are still "running" on your computer. The term "identity software" doesn't mean anything. If you are insinuating that something is spying on you, then no. That's not what's happening. If you don't want to use some online service providers, then don't. If you want to use them, but don't want to reveal them to Fedora Workstation or GNOME, then don't add them to Settings -> Online Accounts. It is all up to you. There is nothing sinister going on here. (In reply to udo from comment #2) > (In reply to Debarshi Ray from comment #1) > Are you too unaware of reality tha there are valid reasons not to use any > 'social' media? See above. If you don't want to use social media, then don't. Nobody is forcing you to. (In reply to udo from comment #4) > Who designed these beautiful dependencies? > # rpm -e gnome-online-accounts-3.20.5-1.fc24.x86_64 > error: Failed dependencies: > libgoa-1.0.so.0()(64bit) is needed by (installed) > libgdata-0.17.5-2.fc24.x86_64 > libgoa-1.0.so.0()(64bit) is needed by (installed) > control-center-1:3.20.2-1.fc24.x86_64 > libgoa-1.0.so.0()(64bit) is needed by (installed) > evolution-data-server-3.20.6-1.fc24.x86_64 > libgoa-backend-1.0.so.1()(64bit) is needed by (installed) > control-center-1:3.20.2-1.fc24.x86_64 > > Who designed this without OFF switch? > Who should not be designing any longer? Please refrain from such sarcasm. See: https://getfedora.org/code-of-conduct (In reply to udo from comment #5) > In general: > One should be able to turn off processes on their own boxes. > (i.e.: because they use CPU, memory, etc) > When there are other reasons as described above the reasons to provide such > an OFF method (as there is no human interaction method provided!) are GREAT. Definitely! You can do whatever you want with your computer. Fedora is free software that you download, or obtain otherwise, of your own free will. It's not thrust upon you. If you don't like it, then you have the freedom to modify it and distribute your modifications. You are also free to use something else. Fedora is about freedom, it is about features. It is not fundamentally about choice. At this point, I suggest that you read http://www.islinuxaboutchoice.com/ (In reply to Stefan Assmann from comment #6) > Agreeing with what Udo says, users should be able to decide if they want to > run goa-daemon or not. Sadly, no. First, a very large percentage of users, including technically aware ones, are not equipped to make those decisions. There are too many lines of code, and nobody knows everything. Sometimes, one might think she knows what a modification will do, without the awareness that it will subtly break the system and be the cause for future frustration. A more reasonable expectation is to not force users to reveal their online identity, and to ensure that the software doesn't get in their way if they choose not to. And it doesn't. If you don't use any online accounts, then the goa-daemon will silently sit in a corner - out of your way. At a time when your web browser consumes gigabytes of memory, a sleeping goa-daemon should hardly be a blip on the horizon. If it isn't, then it is a bug. File it. Think of it as your contribution to free software! (In reply to udo from comment #7) > It is quite obvious that despite the documentation on various interfaces > that the user interface has been totally forgotten here. The GNOME user experience is crafted in the open. Anybody is free to participate. The usual venue is #gnome-design on the GIMPNet IRC network. > Quality control thus is lacking. Quality control needs actionable bug reports. As I said, if you encounter bugs, please file them with precise steps, logs, etc.. > So please PLEASE enable the user to choose. > Either by not starting this software or by removing the bogus RPM > dependencies. (In reply to udo from comment #8) > Choice is the ultimate requirement here. Choice is a concept that's easily bandied about, but needs hard work to get behind it. The choice afforded by free software needs effort. The choice you so demand will explode the maintenance burden of Fedora Workstation by several orders of magnitude. It is unfair to make that demand without stepping up to carry some part of it. Anyway ... I am going to close this as NOTABUG. This is a bug tracker, not a mailing list or discussion forum. Marking it as NEW or ASSIGNED or whatever isn't going to magically lead to the outcome that you are wishing for. On the other hand, NOTABUG conveys the fact that the maintainers of this software don't see a problem here and are not planning to act on it.
(In reply to Debarshi Ray from comment #11) > There are some major misconceptions here. No. You designed stuff without any possibility for the user to opt out. Redhat is not an organ to enable change so I asked you, I tried to apply to your common sense. > There is a lot of code "running" on your computer Not relevant. I choose what needs to go and what can stay. > The term "identity software" doesn't mean anything. Not relevant. I choose what needs to go and what can stay. > If you are insinuating > that something is spying on you, then no. That's not what's happening. Not relevant. I do not need the software. > If > you don't want to use some online service providers, then don't. Yes, but If I do not wnat to have GOA daemon on my system I can NOT. > See above. If you don't want to use social media, then don't. Nobody is > forcing you to. See above, If I do not wnat to have GOA daemon on my system I can NOT. > thrust upon you. If you don't like it, then you have the freedom to modify > it and distribute your modifications. You are also free to use something > else. So you do not deliver a complete product with even the most basic features. ('ON' & 'OFF') And thus say you do that work because it is not in my area of expertise. > Quality control needs actionable bug reports. As I said, if you encounter > bugs, please file them with precise steps, logs, etc.. No OFF is a BIG bug behind the keyboard. That is enough of a BUG. > I am going to close this as NOTABUG. > > This is a bug tracker, I made clear what is missing and did not start a discussion abut a simple BASIC feature that is very missing. The fact that you cannot admit a simple oversight, a differnce of view perhaps, says enough about the bug tracker that you want this to be. Please allow us to not start GOA daemon. Please allow us to not install GOA daemon too, perhaps.
I could also formulate the issue the other way: I could enter bugs against libgdata, control-center and evolution-data-server as they depend on software that we do not use without good cause. I do not think that is a more productive solution than the ability to turn of goa daemon. So please understand the bug: the developer made some very nice documentation about certain interfaces but someone forgot the human interface that I mentioned, OFF or ON, to meet the basic criteria of choice.
I dnf erased goa-daemon. Out with the bath water went something called folks, grilo-plugins, empathy, evolution-data-server and libgdata. Don't think I'll miss any of that. Now, if I could get rid of all the gvfsd-stuff, that would be great.
Over here dependency hell broke loose when I tried to do that: Removing: control-center x86_64 1:3.20.2-1.fc24 @updates 18 M ekiga x86_64 4.0.1-29.fc24 @System 18 M evolution-data-server x86_64 3.20.6-1.fc24 @updates 14 M folks x86_64 1:0.11.2-5.fc24 @System 2.5 M gdm x86_64 1:3.20.1-3.fc24 @System 2.0 M gnome-classic-session noarch 3.20.1-1.fc24 @System 194 k gnome-online-accounts x86_64 3.20.7-1.fc24 @updates 2.2 M gnome-shell x86_64 3.20.4-3.fc24 @updates 9.5 M gnome-shell-extension-alternate-tab noarch 3.20.1-1.fc24 @System 9.4 k gnome-shell-extension-apps-menu noarch 3.20.1-1.fc24 @System 26 k gnome-shell-extension-auto-move-windows noarch 3.20.1-1.fc24 @System 19 k gnome-shell-extension-common noarch 3.20.1-1.fc24 @System 555 k gnome-shell-extension-launch-new-instance noarch 3.20.1-1.fc24 @System 4.9 k gnome-shell-extension-places-menu noarch 3.20.1-1.fc24 @System 23 k gnome-shell-extension-user-theme noarch 3.20.1-1.fc24 @System 7.0 k gnome-shell-extension-window-list noarch 3.20.1-1.fc24 @System 55 k gnome-tweak-tool noarch 3.20.1-1.fc24 @System 1.0 M libgdata x86_64 0.17.7-1.fc24 @updates 1.8 M pulseaudio-gdm-hooks x86_64 8.0-6.fc24 @System 354 So I was reminded on why I didnt that. This brings us back to the lack of understanding of design and empathy for the wishes of the user. So please interpret this as a request to change the functionality of the program as I described and also tweak the dependencies; I showed what unrealistic stuff is hidden in there.
Guess when one doesn't run gnome, gdm, etc, there are fewer dependencies.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Debarshi Ray from comment #11) > There are some major misconceptions here. Yes, I made them clear. Yet you wrote: > Marking it as > NEW or ASSIGNED or whatever isn't going to magically lead to the outcome > that you are wishing for. Magically realizing what basic functionality people need in software (choice!) is of course not to be expected. > On the other hand, NOTABUG conveys the fact that > the maintainers of this software don't see a problem here and are not > planning to act on it. Sure, Yet no one explained what the 'proper' process for grave design issues like this one is if one sees a case for change. If software doesn't meet basic criteria it should not have been published. You did not allow any understanding of the necessities in software I presented. You did not allow for any process to be started by me to effect a certain awareness in the bodies that handled the selection of this software. Certainly GOA is not the only case of software we do not need, but I have to start somewhere, right?
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Nothing was fixed here...
I suppose this is not Fedora-related, since I see this in Linux Mint. I haven't read all comments in this bug report, but I think there is no reason for having goa-daemon occupying significant resources in my computer for no reason.
Here is a *great* workaround on how to disable gnome-online-accounts: --------------------------------------------------------------- rpmdev-setuptree cat > ~/rpmbuild/SPECS/kill-goa.spec << EOF Name: kill-goa Version: 1 Release: 1%{?dist} Summary: Ensures that gnome-online-accounts is disabled License: BSD %description Ensures that gnome-online-accounts is disabled %files %filetriggerin -- /usr/libexec/goa-daemon ln -sf /dev/null /usr/libexec/goa-daemon %changelog * Thu Aug 9 2018 Alexander Korsunsky <alexander.korsunsky> - EOF rpmbuild -bb ~/rpmbuild/SPECS/kill-goa.spec sudo rpm -i ~/rpmbuild/RPMS/x86_64/kill-goa*.rpm sudo dnf reinstall gnome-online-accounts --------------------------------------------------------------- Dear gnome-online-accounts maintainers+devs: please read between the lines. Disabling a piece of software when requested should be one of the first features to implement. Forcing users to use it is not polite.
I noticed a peculiar behaviour of goa-daemon in an X2Go session with Xfce. Maybe it is caused by misbehaviour of X2Go Client. I can create a bugreport at https://www.x2go.org, but I need more information what they should change. Summary: In an X2Go Xfce remote desktop session goa-daemon writes messages into log file until /tmp is full. Computer must be rebooted to be usable again. In the X2Go session starting some programs once (firefox, thunderbird, evolution, evince, eog) stop creation of messages. More information: On our computers we install GNOME, Plasma and Xfce. Xfce is the default desktop environment and used for X2Go remote desktop connections. User accounts are used from Active Directory by SSSD on Fedora 28 x86_64. Home directories are shared by NFS to all GNU/Linux computers. Our dedicated computer for remote access had to be restarted because /tmp had no more free space. The file "/tmp/.x2go-${LOGINNAME}/C-${LOGINNAME}-58-1533023894_stDXFCE_dp32/cmdoutput" was 7.8 GB big, the size of /tmp. The file contained approximately 126*10^6 lines. Each following lines would be repeated in blocks of 10.000 lines of each second: (goa-daemon:4428): goa-daemon-WARNING **: 09:58:25.812: Unsupported account type (null) for ID account_1517941801_1558 (no provider) and of: (goa-daemon:4428): GoaBackend-CRITICAL **: 09:58:25.899: goa_provider_get_for_provider_type: assertion 'provider_type != NULL' failed (goa-daemon:4428): goa-daemon-WARNING **: 09:58:25.899: Unsupported account type (null) for identity (null) (no provider) Messages were created in sub-second intervals. The timeline for the computer was: 09:56 dedicated remote computer restarted because users could not log in with X2Go Client anymore. Error message: ---8<--- Connection failed. -- Your home directory path contains non-ASCII characters. Aborting session startup. [OK] ---8<--- 09:58 user logs in again; goa-daemon process writes to cmdoutput file 15:25 /tmp is full again After locating the cmdoutput file and notice its content I renamed the user's goa configuraton file. The old configuration file has a high amount of matching lines compared to the new one: $ grep '\[Account account' ${HOME}/.config/goa-1.0/accounts.conf.causesMASSIVEoutput-20180731 | wc -l 5376 $ grep '\[Account account' ${HOME}/.config/goa-1.0/accounts.conf | wc -l 18 Users did not configure goa themselves in any way. I am not sure why there is such a high number of matching lines. The new configuration file was created automatically. Messages were still created, but at a much lower rate and amount (3 lines each block; total of 1.5 MB in 2 hours). After the fix the high rate and amount of message creation (10.000 of lines each block with 7.8 GB in 5.5 hours) did not occur again. In hindsight the user caused the problem 2 times before, but I could not find the reason, hence restarted the computer so other users could continue working. When users log out from their X2Go session the associated folder in /tmp will be deleted. While testing today I noticed that the generation of the messages does not depend on the operating system X2Go Client is executed on. Furthermore, the messages are generated only within an X2Go session. The messages show up immediately after start of goa-daemon. The last line in 'cmdoutput' before the messages appear is: dbus-daemon[25105]: [session uid=REDACTED pid=25105] Activating service name='org.gnome.Identity' requested by ':1.52' (uid=REDACTED pid=25889 comm="/usr/libexec/goa-daemon ") Some programs stop the creation of the messages for good, with and without entering your password in the "Unlock Session" window after login to the X2Go session, i.e. evolution, firefox, thunderbird, eog, evince. Some programs require that you have entered the password into the "Unlock Session" window after login to the X2Go session, i.e. gedit. The longer the messages were created already, the longer they seem to be created after starting the above mentioned programs. Something like a backlog? Usually after 1 to 6 message blocks they will not be printed anymore. The affected user used none of the above programs. I can reproduce the behaviour. I can provide log files and configuration files if required. I use evolution in order to connect by EWS to an Microsoft Exchange mail account. Even in X2Go sessions. I have no grudge against goa-daemon. If it is using only a small amount of resources and not causing problems I am fine with it.
Hi, René Genz, the main reason I have for disabling goa-daemon is very similar to yours. I have created a bug report here: bug #1601438 Please check it out and see if your issue is comparable to mine. Regards, Alexander
(In reply to René Genz from comment #23) > Furthermore, the messages are generated only within an X2Go session. This is not true. They are created in a local session too, see `journalctl -f`. I did not notice them, because I start the programs evolution, firefox, eog, or evince immediately after login. Those programs stop the creation of the messages. (In reply to Alexander Korsunsky from comment #24) > have created a bug report here: bug #1601438 > > Please check it out and see if your issue is comparable to mine. That is exactly my use case.
How to also file against evolution-data-server, gvfs-goa, libgdata?
FWIW: this bug is about the dependecy hell that causes our inability to remove software we do not need like in this case gnome-online-accounts. Similar software we do not need: iio-sensor-proxy (we do not have sensors), bolt (we do not have thunderbolt devices). Same could be said for all firmwares, videodrivers, etc, for whichw e do not have the hardware.
(In reply to Alexander Korsunsky from comment #22) > Here is a *great* workaround on how to disable gnome-online-accounts: OMG THANK YOU SO MUCH. one small modification: I used "dnf install" instead of "rpm -i ~/rpmbuild/RPMS/x86_64/kill-goa*.rpm" so I don't get dnf complaining that the rpmdb database has been altered outside dnf.
Closing as per gnome-online-accounts maintainer comments above. Nothing that can be done on gnome-control-center side here.
GOA is an unnecessary package. GOA has no place on our systems. GOA's place need no to be decided by the Fedora project but by the end user. By closing this bug you are stating that this is not our right and you offer us no reasonable opportunity or method to make Fedora better and get rid of GOA on our systems. There is no decent procedure for complaints or any corrective action in this are, at least nobody ever provided this. So this but is another example of autocratic behaviour by poeple that cannot see the perspective of others. Please state the procedure to change start changing the dependency-hell that Fedora is. (GOA, bolt, etc, etc; stuff needs to be much more modular and dependencies need to be much weaker) Please state the procedure to change start changing the architectural decisions that fedora makes: networking-scripts is that hard to maintain versus NM? systemd is really what we wanted?
(In reply to Pete Walter from comment #29) > Closing as per gnome-online-accounts maintainer comments above. Nothing that > can be done on gnome-control-center side here. Comments as in: https://bugzilla.redhat.com/show_bug.cgi?id=1379070#c1 ? Or this one? https://bugzilla.redhat.com/show_bug.cgi?id=1379070#c9 Or the nonsense in https://bugzilla.redhat.com/show_bug.cgi?id=1379070#c11 ? He even starts mentioning the form instead of the contents so he has no real arguments. He even explains oeple cannot decide. (but he can?!) And all of that is reason to close the bug? Where in the Netherlands can I meet a fedora representative that is 'high up' that I can explain these issues to so that someone can *really* take a look at them? When we have no representation that I can speak of then our representation is here. And not having a software on a system is a reasonable request.
(In reply to Pete Walter from comment #29) > Closing as per gnome-online-accounts maintainer comments above. Nothing that > can be done on gnome-control-center side here. Why not reassign then? I will try to address the "maintainer comments above": (In reply to Debarshi Ray from comment #11) > First, a very large percentage of users, including technically aware ones, > are not equipped to make those decisions. There are too many lines of code, > and nobody knows everything. Sometimes, one might think she knows what a > modification will do, without the awareness that it will subtly break the > system and be the cause for future frustration. That is fair enough, but this is a separate daemon, a separate binary and absolutely not crucial for system function. Even if you leave it enabled by default, why not at least give the power users a dconf option or better yet wrap it in a systemd unit that can be masked? I've been running with my "workaround" hack which is basically just ensuring that the process binary is deleted, and no, it does not "break everything". The list of things it "breaks" is: - gnome-documents doesn't launch - A journal message when opening the online account settings in gnome-control-center - An on-screen message when I open gnome-todo - Nautilus can't show google drive That's it! I can live with that, and if I disable goa, then this is on me. But not giving me the option to, and effectively forcing me to use it (no GNOME for you unless goa is running!) is not polite. There is absolutely no reason that this is a hard dependency of the whole GNOME suite. At most, it's a hard dependency of gnome-documents. > [...] and to ensure that the software doesn't get in their way if they > choose not to. And it doesn't. > If you don't use any online accounts, then > the goa-daemon will silently sit in a corner - out of your way. At a time > when your web browser consumes gigabytes of memory, a sleeping goa-daemon > should hardly be a blip on the horizon. If it isn't, then it is a bug. File > it. That is incorrect. On the default install of Fedora when using Kerberos logins (for example with FreeIPA), gnome-online-accounts spams the system so hard that the journal fills up peoples system partitions. This is bug #1601438, and you haven't even reacted to that one yet. Now I wouldn't be blaming you for not having a Off-switch in a system-critical, mature and relatively bug free component. I also wouldn't be blaming you for including a newer and immature component as long as it has an off-switch, because this is Fedora after all. But an immature, buggy and mostly unnecessary component without an Off-switch is a problem.
I would just like to thank Alexander Korsunsky for fighting for what seems like an obvious common sense approach here. I would also like to suggest a general review of memory usage under a standard gnome-shell fedora install. In my case I have 4Gb of ram and found that I was almost always swapping under light load. After a quick check I found that at times gnome was using 3.5Gb with nothing else running. I have no external services connected with it, and don't use evolution or any mail client or calendar. Here are some memory usage (RES) stats from that at the time of checking: gnome-software 1.8Gb packagekitd 1Gb gnome-shell (my user) 448Mb gnome-shell (gdm) 258Mb gnome-software --gapplication-service (99Mb) nautilus --gapplication-service (70Mb) gjs-console gnome-documents --gapplication-service (70Mb) Xorg (50Mb) seapplet (44Mb) systemd-journald (37Mb) libvirtd (37Mb) firewalld (37Mb) goa-daemon (32Mb) evolution-addressbook-factory-subprocess (29Mb) evolution-calendar-factory (27Mb) evolution-addressbook-factory-subprocess (26Mb) tracker-miner-fs (26Mb) evolution-source-registry (26Mb) evolution-addressbook-factory (26Mb) abrt-applet (26Mb) Obviously gnome-software and packagekitd are the big offenders here. The extra instance of gnome-shell for GDM which even discounting the 99Mb of SHR seems like a big waste. I don't even know what gjs-console for gnome-documents is. The cluster at the bottom from goa-daemon to evolution-addressbook-factory all appear to be for services that I don't use and while individually quite small total up to hundreds of Mb.
Fedora 28. By the way.
I also think we should be able to easily disable and uninstall GNOME Online Accounts. This is the GNU/Linux philosophy. Please improve Fedora by letting the user control what he needs/wants. Of course, not all requests are easily/feasible to satisfy but it's not the case. I tend to see developers investing a large amount of effort trying to convince reporters they're wrong. Developers do an excellent job. Proper software development does not exist without feedback. If there is no feedback, then the software is not being used. People who spend time reporting should also be valued. Thanks.
It is a bug if you know what freedom of choice and better than average (at best0 design is. Look at what the designed. It simply lacks the *most* *basic* thing: The ability to turn the thing off or to completely remove it. I am not alone here. This issue was mentioned at the fesco thing.
I begin to think there's politics behind forcing us to run Gnome Online Accounts.
It's probably more like this discussion, started over two years ago, doesn't belong in bugzilla and should be taken up in one of @lists.fedoraproject.org, devel or users.
Or fesco to get some decent developer guidelines. It is a shame that apparently trivial situations like this one are covered nowhere in Fedora. Or are they?
I'm getting spammed by goa-daemon, any way of turning it off as for today ?
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Any way of turning goa-daemon off?
Is this still an issue after 3 years? This is akin to the behaviour of a company like Microsoft, not free software. How can this even be debatable? Being forced to run a program we don't need, don't want, how is this compatible to the free software philosophy and not considered a major bug? I simply can't understand the stubbornness of some people. There may be commercial interests behind, that would justify such a behaviour, and would be even worst than incompetence. From time to time I think about experimenting other distros but "small" issues like these make me realise I shouldn't bother.
We have a workaround for this in comment 22. We apparently have no process to guarantee even the most basic controls in a piece of software. We do have a process to admit software to the Fedora distro but that process does apparently not pay attention to details like the OFF switch, dependencies, removability, etc, etc. The question is how long until these deficiencies are fixed?
This works for me in Arch: /etc/dbus-1/services/org.gnome.Identity.service [D-BUS Service] Name=org.gnome.Identity Exec=/bin/false and /etc/dbus-1/services/org.gnome.OnlineAccounts.service [D-BUS Service] Name=org.gnome.OnlineAccounts Exec=/bin/false and reboot. The two daemons only seem to run now if I visit the online accounts page in gnome-control-center. None of my other apps will trigger them and no errors in the log.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Just great: I just tried removing gnome-online-accounts in Fedora 32 and ended with an unusable machine. Thanks, Fedora team. It's more important for you to be stubborn than intelligent.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This persists in the LATEST release, Fedora 33. How do I disable it? I *really* want to post ALL 4million-ish lines logged for goa-daemon...but...I'll be nice and just post a snippet below: $ cat /etc/fedora-release Fedora release 33 (Thirty Three) $journalctl |grep goa-daemon | wc -l 3746167 $ journalctl | tail Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550829564_10756 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550829593_10610 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550829647_10762 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550829656_10764 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550829745_194960 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550829761_10627 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550829774_10774 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550830001_10790 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550830172_10804 (no provider) Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550830231_10662 (no provider)
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
No solution was offered. When you force software onto us, please allow us to decide about running it.
@udovdh I was suffering from this issue too. My workaround has been to switch to a different desktop environment and remove all the stuff related to Gnome. I can highly recommend that, since then my user experience is very smooth.
I have also moved to another GNU/Linux distro: Mint with MATE and afterwards Cinnamon, but Cinnamon shows the same behavior: https://github.com/linuxmint/cinnamon/issues/10065#issuecomment-830381747
A distro switch is kind of a step...
Unfortunately this is still an issue, I understand that some developers are being paid by google to add these garbage into linux, so those devs will definitely refuse to remove goa from our systems. I'm running Fedora 35 Cinnamon spin and here is my solution: remove the packages without touching any dependencies: ------------------------------------- rpm --nodeps -e geoclue2 rpm --nodeps -e gnome-online-accounts rpm --nodeps -e gvfs-goa rpm --nodeps -e iio-sensor-proxy rpm --nodeps -e libgdata rpm --nodeps -e liboauth rpm --nodeps -e onboard rpm --nodeps -e onboard-data add this to /etc/dnf/dnf.conf so nobody can re-install them: ------------------------------------- exclude=geoclue2,gnome-online-accounts,gvfs-goa,iio-sensor-proxy,libgdata,liboauth,onboard,onboard-data
@Dimitris: thanks, buit we're not there yet: When doing dnf update: Problem: package xdg-desktop-portal-1.12.1-1.fc35.x86_64 requires geoclue2 >= 2.5.2, but none of the providers can be installed Thus I try: # rpm -e xdg-desktop-portal error: Failed dependencies: xdg-desktop-portal >= 1.5.4 is needed by (installed) xdg-desktop-portal-gtk-1.12.0-1.fc35.x86_64 # rpm -e xdg-desktop-portal xdg-desktop-portal-gtk error: Failed dependencies: xdg-desktop-portal-gtk >= 1.8.0 is needed by (installed) gnome-shell-41.2-1.fc35.x86_64 I.e.: dependency HELL. Whoever made a DBUS-portal whatever depend on the stuff it could (!) provide (and not only vice versa) is not understanding stuff properly.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.
Ben, this bug still persists in Fedora 36. Is there any reason why this bug was closed, instead of updating version?
(In reply to andersbk from comment #49) > $ journalctl | tail > Dec 11 08:45:49 quail goa-daemon[2012]: Unsupported account type (null) for ID account_1550829564_10756 (no provider) You have broken configuration, that needs fixing. How that happened is the main question. Opening Settings->Online Accounts should show you the accounts. Otherwise ~/.config/goa-1.0/accounts.conf contains the information - do not touch it when the goa-daemon is running. --------------------------------------------------------------------------------------------------- You cannot disable goe-daemon, it's used by the core parts of the GNOME. Thinks like the beginning of the comment #55 are not nice. Think twice before doing any such thing, please. In any case, this is not Fedora specific, if you need any such thing, ask the upstream to implement it: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues
(In reply to Dimitris from comment #55) [...] > add this to /etc/dnf/dnf.conf so nobody can re-install them: > ------------------------------------- > exclude=geoclue2,gnome-online-accounts,gvfs-goa,iio-sensor-proxy,libgdata, > liboauth,onboard,onboard-data make sure you comment this when upgrading fc distro or else you won't be able to "dnf system-upgrade download", it will fail with: Problem: The operation would result in removing the following protected packages: gnome-shell
>Resolution: --- → NOTABUG I beg to disagree. Just because upstream considers this working as intended, this is not how I expect bits of Fedora system to work. I don't use online accounts in gnome, I don't even use the gnome desktop, so I expect to be able to disable unused components. I use this low mem laptop because it is fanless and has a great linux friendly keyboard, so why should I tolerate a useless process consuming precious system resources?
(In reply to Milan Crha from comment #60) [...] > > In any case, this is not Fedora specific, if you need any such thing, ask > the upstream to implement it: > https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues again, this is not how I expect Fedora bug reporting to work. I use Fedora, not linux from scratch, therefore I expect Fedora to act on users behalf in relation to upstread, not users to hunt down every upstream source.
Well, from my point of view, and as my own personal understanding and opinion, Fedora, the same as any/many other distro(s), is trying to stick with upstream, without custom changes. If you'd ever try to manage a package, you will know very well that any divergence from the upstream costs a lot, not only on the package maintenance level (keeping the custom patches applicable and *working properly*), but also from the user's expectations (it's wise to avoid questions like "why package X behaves in distro A as Y, while exactly the same version of the same package behaves in distro B as Z?"). You have very specific request (in the context of this specific package), and it'sa good request, from my point of view, but it should be better served upstream, thus everyone benefits from it, not only you or a specific distro users. Not giving to others is kinda selfish, which is not The Open Source way. You have ways to influence this, it's only not here, it's in the upstream. The link is above. You have also workarounds, but they can have side effects. There's nothing more I can say about this, I'm sorry.
This package is still in the distro and wasting resoources. What a shame! There was an intriguing comment by some genius that Fedora is about freedom and not about choice. Can there be freedom without choice? Seems like M$ crowd has taken over Linux.