Bug 347219

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.

> 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

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).

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

One possible solution is adding an env variable and patching the install prefix.

That's the only solution we have right now.

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

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

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

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.

> 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.

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!

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.

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.

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?

FYI: bug-status in Ubuntu=critical

FYI: not our problem.

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).

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.

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.

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

Matt, the last commit should fix it for good.

Let me know if there are still troubles.

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.

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

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

This still happens and I'm Kubuntu 16.04. https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1574045

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.