[Bug 1574045] Re: Can't install account-plugin-google; kaccounts-providers already provides /usr/share/accounts/providers/google.provider
Bug Watch Updater
1574045 at bugs.launchpad.net
Sat Apr 23 17:39:27 UTC 2016
Launchpad has imported 27 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=347219.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2015-05-05T11:08:16+00:00 Jonathan Riddell wrote:
This file overlaps with a file in gnome's account-plugin-facebook
/usr/share/accounts/services/facebook-im.service
and kaccounts-providers has a file which overlaps with gnome's account-plugin-google
/usr/share/accounts/providers/google.provider
gnome and kde need to be co-installable so these files should be renamed
to not overlap.
As a separate but related issue if ktp explodes because gnome accounts-
plugins are installed that should also be gracefully delt with.
Reproducible: Always
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/0
------------------------------------------------------------------------
On 2015-05-05T11:21:46+00:00 Mklapetek wrote:
It cannot be gracefully dealt with because Gnome uses different system
for creating their (telepathy) accounts and KAccounts has no way of
knowing which provider is for gnome and which is for kde. To KAccounts,
all is the same.
The way gnome creates telepathy accounts is also incompatible with ktp,
this _will_ result in user having invalid ktp accounts. I am working on
making these compatible, but for now they aren't and will not be till
15.08. There's nothing that can make it compatible.
facebook-im.service will not be installed from 15.04.1 as facebook chat
support is deprecated.
Simply renaming all the files is also not a good option, because if
you'll have both packages installed, you will have duplicated entries,
each doing different things.
I'm afraid these two simply aren't co-installable.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/1
------------------------------------------------------------------------
On 2015-05-05T15:53:31+00:00 Jonathan Riddell wrote:
> I'm afraid these two simply aren't co-installable.
that's quite a big fail compared to the normal setup for linux desktops. if we can't install two applications from gnomey stuff and kdey stuff at the same time that breaks package install for an awful lot of people
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/2
------------------------------------------------------------------------
On 2015-05-06T09:21:25+00:00 Mklapetek wrote:
Yes, well, apparently nobody has thought about that.
Quoting Accounts SSO developer:
"hi! I'd say that the problem is on the .provider files only, because the service files refer to a provider, so as long as that's a different one, they won't mess up
I admit I don't have a solution for the .provider files anyway...
one possibility is to play with environment variables, to instruct
libaccounts-glib to look for its files in a different directory"
So for now the only solution is to rename and use different install dir
and use an env variable (I'm not sure which one yet).
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/3
------------------------------------------------------------------------
On 2015-11-12T16:45:02+00:00 Scarlett Clark wrote:
We still have a growing number of bug reports piling up on launchpad in regards to this bug.
I expect it is because many ubuntu users will have gnome stuff..
https://bugs.launchpad.net/kubuntu-ppa/+bug/1451728
Any progress?
Scarlett
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/4
------------------------------------------------------------------------
On 2015-11-12T17:02:46+00:00 Mklapetek wrote:
One possible solution is adding an env variable and patching the install
prefix.
That's the only solution we have right now.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/5
------------------------------------------------------------------------
On 2016-01-15T09:13:00+00:00 Flames_in_Paradise wrote:
This is a real blocker - so... Multi-Desktop environment (still
recommended?) puts interested peoples desktop in a unsecure state as it
blocks APT then.
If there is no other solution we will have to ask to remove Telepathy
from Kubuntu-meta or _not_ to recommend a mixed Desktop-Environment any
longer & put up a warning. May sound harsh, but...
This error covers two release + a third that's in current development.
A possible solution to get at least APT back into it's shoes again was
posted in askubuntu:
https://askubuntu.com/questions/618389/error-upgrading-kde-telepathy-
kubuntu-15-04
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/6
------------------------------------------------------------------------
On 2016-01-18T19:56:12+00:00 Mklapetek wrote:
Git commit 0b2bbbb1ca9266e8e2c9b685d4d44f1d69822b03 by Martin Klapetek.
Committed on 18/01/2016 at 19:55.
Pushed by mklapetek into branch 'master'.
Disable the KCM if AG_PROVIDERS and/or AG_SERVICES are empty
M +112 -0 src/kaccounts.cpp
http://commits.kde.org/kaccounts-
integration/0b2bbbb1ca9266e8e2c9b685d4d44f1d69822b03
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/7
------------------------------------------------------------------------
On 2016-01-18T19:56:27+00:00 Mklapetek wrote:
Git commit 0ba1dde28cfacff71b264bba1b43a3f6e5992406 by Martin Klapetek.
Committed on 18/01/2016 at 19:55.
Pushed by mklapetek into branch 'master'.
Force the installation of providers and services to
$CMAKE_INSTALL_PREFIX/share/kaccounts
Because distros are unable to solve this file conflict, this will now
force all providers and services to be installed in own directory to
which libaccounts-glib needs to be pointed by env vars. Things won't
work without those env vars.
FIXED-IN: 16.04.0
M +18 -42 src/lib/cmake/FindAccountsFileDir.cmake
http://commits.kde.org/kaccounts-
integration/0ba1dde28cfacff71b264bba1b43a3f6e5992406
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/8
------------------------------------------------------------------------
On 2016-01-31T01:32:13+00:00 Matthew Scheirer wrote:
I just recently adopted KTP in the AUR and am having trouble with this
change. Is it really necessary to introduce superfluous envvars (I don't
think any KDE packages in Arch are shipping /etc/profile entries for
anything at all, and I don't think anyone is going to propose pushing
AG_PROVIDERS and AG_SERVICES into startkde), which means I'd have to add
/etc/profile/kaccounts-integration.sh to support these envvars. It seems
like Ubuntu should just be making kaccounts-integration and their
account-pluigins packages conflict one another. The two providers that
are common between them (twitter and google) are identical.
I'm not sure in what use case a provider or service file for accounts-
sso will be desktop specific. Is there a reason they are not in an
upstream accounts-sso project? I read all the ones Canonical provides
and all the ones KDE had in the old ktp-accounts-kcm package and besides
translation names I'm not seeing whats unique.
Speaking of ktp-accounts-kcm, all those provider files were prefixed
with ktp-*. Maybe that would be a better answer here - just prefix KDE
providers with kde-google.provider, etc? There are only three of them
right now anyway, though now that I'm here I'm looking to port over /
add more, because I'd love to get libpurple-matrix support in KTP.
I'd have no problems poking the accounts-sso or Launchpad team behind
account-plugins for a better solution to this. From my understanding the
design of accounts-sso is entirely so that different packages could put
different providers in share/accounts/providers and have them show up in
clients like kaccounts.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/9
------------------------------------------------------------------------
On 2016-01-31T17:01:46+00:00 Mklapetek wrote:
> Is it really necessary to introduce superfluous envvars
> It seems like Ubuntu should just be making kaccounts-integration and their account-pluigins packages conflict one another.
Yes, please go talk to them. I've tried. More than once.
> I don't think anyone is going to propose pushing AG_PROVIDERS and
AG_SERVICES into startkde
No; kaccounts needs to install its own file to /etc/profile, which unfortunately
I've been too busy to fix and semi-forgot.
> The two providers that are common between them (twitter and google)
are identical.
They are not and that's the problem.
> I'm not sure in what use case a provider or service file for accounts-
sso will be desktop specific.
When you want your users to connect/share/use through "KDE" and not "Unity"
or whatever Ubuntu is using.
For the rest, read comment #1.
> I'd have no problems poking the accounts-sso or Launchpad team behind
account-plugins for a better solution to this
Please do so if you think that. Just so you know, though, accounts-sso is moreless
in maintenance mode, there is nobody actively working on it.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/10
------------------------------------------------------------------------
On 2016-01-31T18:58:03+00:00 Matthew Scheirer wrote:
I made a bug report against the account-providers package on Launchpad:
https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1540135
If I don't hear a reply soon I'll start poking pspmteam members. It
would be insane to go against accounts-sso standards because Ubuntu
package maintainers can't fix dependencies, especially when they are the
only distro shipping their account-plugins in the first place!
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/11
------------------------------------------------------------------------
On 2016-02-01T17:39:11+00:00 Mklapetek wrote:
The bigger problem this actually brings is that Mission Control
is using the accounts-sso plugin to read your accounts and make
them available to Telepathy.
But it is now failing on AppArmor because it does not allow
Mission Control to access those files at the new location.
So if I don't find a solution for that^, then I will revert this fix
and let buntu remove ktp from their archives, if they wish to
do so.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/12
------------------------------------------------------------------------
On 2016-02-02T13:38:02+00:00 Matthew Scheirer wrote:
The upstream solution does not actually work (it uses libaccounts-glib
envars to set alternative profile directories, but apparmor will deny
kaccounts access to those files, and would require permissions
modifications in the Debian packages) and it breaks accounts-sso
intended use (because by design, you should be placing accounts in
/usr/share/accounts from multiple provider packages, which in theory
could be third party).
The best case scenario would be that common providers like
google.provider or twitter.provider would be unified into a shared
project between the two groups, since the actual provider files are
extremely similar to one another and could be unified (if you want the
respective files I can upload them here as well, this is just a pretty
quick reference): http://i.imgur.com/z3U67z4.png
The problem on that front is that accounts-sso is seeing very little
development and is effectively in maintenance mode.
Having these packages conflict actually does not break either KDE's
Telepathy or Ubuntu's Empathy - the KDE client will still load Ubuntu
providers, and vice versa. The problem is they provide the same files,
and thus should conflict regardless.
You could be more selective and just make account-plugin-google and
account-plugin-twitter conflict for now, because then regardless of
which packages you have installed google and twitter signon
functionality would work. The KDE package however is not just those
provider files - it also includes GUI dialogs for owncloud and generic
services enablement. But then the problem becomes as KTP adds more
services to its online accounts you get additional conflicts.
Fundamentally though KDE should not be patching their system settings
dialogs because of a package conflict in a single distro that also
breaks the Telepathy standards and introduces what would be one of very
few instances of the KDE desktop imposing system wide environment
variables. Either accounts-sso unifies common provider files in a shared
project, or you just make packages providing the same providers conflict
with one another.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/13
------------------------------------------------------------------------
On 2016-02-02T13:44:37+00:00 Matthew Scheirer wrote:
Ignore that last one, I should not be explaining with Ubuntu devs just
after waking up in the morning.
If you can, comment on the Launchpad bug, Mardegan wants to talk about
making a shared package, which I guess would end up in accounts-sso?
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/14
------------------------------------------------------------------------
On 2016-02-08T21:53:45+00:00 Flames_in_Paradise wrote:
FYI: bug-status in Ubuntu=critical
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/15
------------------------------------------------------------------------
On 2016-02-08T22:28:43+00:00 Mklapetek wrote:
FYI: not our problem.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/16
------------------------------------------------------------------------
On 2016-02-09T05:52:02+00:00 Damon Lynch wrote:
Martin, I reported this bug May last year. I don't know what is more of
an eye-opener -- the fact that it came up at all (indicating developers
and even packagers don't install more than one desktop), or your "not
our problem" response to the news that the bug is critical (which it
is).
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/17
------------------------------------------------------------------------
On 2016-02-09T07:05:22+00:00 Mklapetek wrote:
As Matt correctly points out above, it is /only/ problem with
Ubuntu (Unity, to be more exact). But there is exactly zero
willingness from Ubuntu packagers/developers to sort this
out other than "this is KDE's problem" and "we'll ask to pull
Telepathy from Kubuntu", as you can read in comment #6.
Now, as you can infer from comments #7 and #8, as well as
from the state of this bug, I /did/ actually fix this in a way that
was recommended by Alberto, the upstream accounts-sso guy,
who is the only helpful human in this issue.
If Ubuntu's bug is still at critical level, what am I supposed to do?
That is not our problem, we did fix this on our side as per
recommendations. Telling us that some random Ubuntu bug
is critical is just pointless.
This fix however brought up different issues, which again are present
mostly in Ubuntu-only with their AppArmor profile for Telepathy.
Now this is, again, not our problem, but if you would read the report
linked by Matt, I did propose an alternate solution which would work
for everyone.
I don't know what else you want me to do to make your distro happy.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/18
------------------------------------------------------------------------
On 2016-02-09T14:09:18+00:00 Matthew Scheirer wrote:
If Ubuntu wants their "critical" bug fixed, they make kaccounts-
providers conflict with account-plugins. The fact they are refusing to
do so is insane, because the whole reason this is a problem in the first
place is that apps using accounts-sso will produce duplicate account
configuration options if we have duplicates in the profiles dir.
This is the most "not KDE's problem" of any problem ever. We're using an
Intel framework for accounts management the way it is intended, as are
Canonical, and by design when two messaging providers provide the same
service they should conflict one another rather than provide redundant
entries that mess up the GUIs.
How is the practicality of adding a KDE specific tag to our provider
files and then renaming them with a prefix? I can go dig into the
kaccounts-integration code and see if its possible. That doesn't solve
the implementation and design problem around accounts-sso that a user of
accounts should be loading all the providers it finds to allow third
parties to provide account support, but I'm pretty sure we all know
nobody is ever going to do that with the state accounts-sso and
telepathy are in.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/19
------------------------------------------------------------------------
On 2016-02-17T18:44:27+00:00 Mklapetek wrote:
Git commit 2307d7df60ee8df6467157305a48e1b5bfd924b6 by Martin Klapetek.
Committed on 17/02/2016 at 18:44.
Pushed by mklapetek into branch 'master'.
Rename the provider files we ship
This is a different fix for 347219 to make Ubuntu happy, but also to
make everyone else happy.
The files will now not overlap anymore, which should fix Ubuntu
packaging. The problem now got moved to the account management UIs,
which we can fix on our side if we need to.
R +0 -0 providers/kde-google.provider.in [from: providers/google.provider.in - 100% similarity]
R +0 -0 providers/kde-owncloud.provider.in [from: providers/owncloud.provider.in - 100% similarity]
R +0 -0 providers/kde-twitter.provider.in [from: providers/twitter.provider.in - 100% similarity]
http://commits.kde.org/kaccounts-
providers/2307d7df60ee8df6467157305a48e1b5bfd924b6
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/20
------------------------------------------------------------------------
On 2016-02-17T18:45:57+00:00 Mklapetek wrote:
Matt, the last commit should fix it for good.
Let me know if there are still troubles.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/21
------------------------------------------------------------------------
On 2016-02-17T20:21:28+00:00 Mklapetek wrote:
Ok, turns out this actually breaks everything as the provider
id needs to match the filename.
So we've brainstormed this with Alberto again and we have
a better solution, which will involve a patch to libaccounts-glib
to look into /usr/share/accounts/{providers, services}/$XDG_CURRENT_DESKTOP/*
with /usr/share/accounts/{providers, services}/* as a fallback.
This way we can install our files into special directory without
needing any new env vars and/or changes in AppArmor and/or
needing to rename anything. All this will need is a new release
of libaccounts-glib.
I'll keep this bug updated.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/22
------------------------------------------------------------------------
On 2016-02-24T01:49:44+00:00 Mklapetek wrote:
Git commit a60c1636b6bf0bf5b0718d8de06facfa959ad719 by Martin Klapetek.
Committed on 24/02/2016 at 01:47.
Pushed by mklapetek into branch 'master'.
Bump libaccounts dep versions
KAccounts now also requires libaccounts-glib 1.21 to ensure the multi-
desktop solution for bug 347219 actually works (which it does only with
>= 1.21)
M +3 -1 CMakeLists.txt
http://commits.kde.org/kaccounts-
integration/a60c1636b6bf0bf5b0718d8de06facfa959ad719
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/23
------------------------------------------------------------------------
On 2016-02-24T01:53:16+00:00 Mklapetek wrote:
Git commit deff781ae751f2f1c95b24997d01aa38c0dd7502 by Martin Klapetek.
Committed on 24/02/2016 at 01:49.
Pushed by mklapetek into branch 'master'.
Update the providers/services install path to not collide on Ubuntu
This now definitely closes bug 347219. Now it's up to Ubuntu to fix
their packages.
M +4 -2 src/lib/KAccountsMacros.cmake
http://commits.kde.org/kaccounts-
integration/deff781ae751f2f1c95b24997d01aa38c0dd7502
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/24
------------------------------------------------------------------------
On 2016-04-23T16:31:25+00:00 Enkouyami wrote:
This still happens and I'm Kubuntu 16.04.
https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1574045
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/27
------------------------------------------------------------------------
On 2016-04-23T16:38:21+00:00 Mklapetek wrote:
Please don't report Kubuntu bugs here.
This bug is fixed and is fixed properly from our side.
There is _NOTHING_ more we can do about that, this is purely
Kubuntu's bug now.
Reply at: https://bugs.launchpad.net/ubuntu/+source/account-
plugins/+bug/1574045/comments/29
** Changed in: kaccounts-providers
Status: Unknown => Fix Released
** Changed in: kaccounts-providers
Importance: Unknown => High
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kaccounts-providers in Ubuntu.
https://bugs.launchpad.net/bugs/1574045
Title:
Can't install account-plugin-google; kaccounts-providers already
provides /usr/share/accounts/providers/google.provider
To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1574045/+subscriptions
More information about the kubuntu-bugs
mailing list