Re: [Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
Hello, Hans! I am sorry for not being more helpful, but I really do not have anything more to say than: If you think, it is covered, it is covered. If you think, it is all duplicates, then it will be the case, I trust. HG, PvdL -- Philipp von der Linden, M.A. OsloerStr.93 D-13359 Wedding eMail: "PvdL" On 30.05.2017 21:01, Hans Joachim Desserud wrote: > I've read through this now, but just to double-check: > There's various bug reports with package-conflicts for files in > '/etc/signon-ui/webkit-options.d/*' between account-plugins and > kaccounts-providers. (For instance bug 1617564) > >>From what I see, this issue will remove the conflicting files from the > account-plugins side and thus fix the issue. Does that mean that these > other issues should all be marked as duplicates of this one? > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
I've read through this now, but just to double-check: There's various bug reports with package-conflicts for files in '/etc/signon-ui/webkit-options.d/*' between account-plugins and kaccounts-providers. (For instance bug 1617564) >From what I see, this issue will remove the conflicting files from the account-plugins side and thus fix the issue. Does that mean that these other issues should all be marked as duplicates of this one? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
Here is my output for /etc/signon-ui/webkit-options.don a 16.10 desktop system that was upgraded from 16.04: $ dpkg -S /etc/signon-ui/webkit-options.d/* account-plugin-google: /etc/signon-ui/webkit-options.d/accounts.google.com.conf account-plugin-twitter: /etc/signon-ui/webkit-options.d/api.twitter.com.conf account-plugin-identica: /etc/signon-ui/webkit-options.d/identi.ca.conf account-plugin-windows-live: /etc/signon-ui/webkit-options.d/login.live.com.conf account-plugin-flickr: /etc/signon-ui/webkit-options.d/login.yahoo.com.conf account-plugin-facebook: /etc/signon-ui/webkit-options.d/www.facebook.com.conf $ These are conffiles. It is not sufficient to stop shipping them in the package, you must also remove them from the filesystem on upgrade using dpkg-maintscript-helper. You can do this, for example, by adding a file debian/account-plugin-google.maintscript to your packaging which contains the following line: rm_conffile /etc/signon-ui/webkit-options.d/accounts.google.com.conf 0.13+16.04.20161212~ account-plugin-google You need to do this for each of the packages which is removing a conffile. And this change also needs to be made for 16.10 and 17.04, since users of those releases who upgraded from 16.04 will still have those files left behind. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
Can some admin please remove the packages from -proposed? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Tags removed: verification-needed ** Tags added: verification-failed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Branch linked: lp:~ci-train-bot/account-plugins/account-plugins- ubuntu-xenial-1669 ** Branch linked: lp:~ci-train-bot/gnome-control-center-signon/gnome- control-center-signon-ubuntu-xenial-1669 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Branch linked: lp:~mardy/account-plugins/webkit-files-1565772 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Branch unlinked: lp:~mardy/gnome-control-center- signon/username-1565772 ** Branch unlinked: lp:~mardy/account-plugins/usernames-1565772 ** Branch unlinked: lp:~ci-train-bot/account-plugins/account-plugins- ubuntu-xenial-landing-062 ** Branch unlinked: lp:~ci-train-bot/gnome-control-center-signon/gnome- control-center-signon-ubuntu-xenial-landing-062 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
A couple of notes about this bug verification: While the ultimate goal of these proposed packages is to solve the co- installation errors of Unity and KDE in Ubuntu due to a number of file conflicts, this proposed upload alone won't be enough to solve the whole issue, which is mainly due to bug 1451728. I suggest verifying this bug by: 1) Creating Google, Facebook, Twitter and Flickr accounts and verify that there are no regressions (that is, that the account creation succeeds and that the user name is properly assigned on the newly created accounts) 2) Verifying that a number of files have been removed under /etc/signon-ui/webkit-options.d/; mainly, verify that the file /etc/signon-ui/webkit-options.d/www.facebook.com.conf is not being shipped by "account-plugin-facebook" anymore. If you are a KDE user, please also try installing "kaccounts-providers" from this PPA: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-misc/+packages and check that there are no file conflicts against our "account- plugin-*" packages. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
Thanks Martin On Mon, Aug 29, 2016 at 2:11 PM, Martin Pitt wrote: > g-c-signon now has a higher version in yakkety, resetting to v-needed. > > ** Tags removed: verification-failed > ** Tags added: verification-needed > > ** Changed in: gnome-control-center-signon (Ubuntu Yakkety) >Status: In Progress => Fix Released > > ** Changed in: account-plugins (Ubuntu Yakkety) >Status: In Progress => Fix Released > > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1565772 > > Title: > [SRU] Allow plugins to decide which username to set on new accounts > > To manage notifications about this bug go to: > https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
g-c-signon now has a higher version in yakkety, resetting to v-needed. ** Tags removed: verification-failed ** Tags added: verification-needed ** Changed in: gnome-control-center-signon (Ubuntu Yakkety) Status: In Progress => Fix Released ** Changed in: account-plugins (Ubuntu Yakkety) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
Same for account-plugins -- this was marked for being fixed in y, but the comment that closes it was for xenial already, and yet the xenial task is still open. This is horribly confusing and wrong, so I mark as v-failed for the time being as at least the wrong gnome-control-center- signon in yakkety needs to be fixed. ** Changed in: account-plugins (Ubuntu Yakkety) Status: Fix Released => In Progress ** Tags removed: verification-needed ** Tags added: verification-failed ** Changed in: account-plugins (Ubuntu Yakkety) Assignee: (unassigned) => Alberto Mardegan (mardy) ** Changed in: gnome-control-center-signon (Ubuntu Yakkety) Assignee: (unassigned) => Alberto Mardegan (mardy) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: In Progress Status in gnome-control-center-signon package in Ubuntu: In Progress Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: In Progress Status in gnome-control-center-signon source package in Yakkety: In Progress Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
Argh, I saw too late that this is already marked as fixed for yakkety , but the version there is 0.1.9+16.04.20160405-0ubuntu1 . I. e. it is smaller than the version in xenial, which breaks upgrades. This is a blocker for releasing the update, so y needs to be updated ASAP. ** Changed in: gnome-control-center-signon (Ubuntu Yakkety) Status: Fix Released => In Progress ** Changed in: account-plugins (Ubuntu Xenial) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: In Progress Status in gnome-control-center-signon package in Ubuntu: In Progress Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: In Progress Status in gnome-control-center-signon source package in Yakkety: In Progress Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
Hello Alberto, or anyone else affected, Accepted gnome-control-center-signon into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source /gnome-control-center-signon/0.1.9+16.04.20160719-0ubuntu1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: gnome-control-center-signon (Ubuntu Xenial) Status: Confirmed => Fix Committed ** Tags removed: verification-done ** Tags added: verification-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: In Progress Status in gnome-control-center-signon package in Ubuntu: In Progress Status in account-plugins source package in Xenial: Fix Committed Status in gnome-control-center-signon source package in Xenial: Fix Committed Status in account-plugins source package in Yakkety: In Progress Status in gnome-control-center-signon source package in Yakkety: In Progress Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Confirmed Status in gnome-control-center-signon source package in Xenial: Confirmed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Changed in: canonical-devices-system-image Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Released Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Confirmed Status in gnome-control-center-signon source package in Xenial: Confirmed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Branch linked: lp:~ci-train-bot/account-plugins/account-plugins- ubuntu-xenial-landing-062 ** Branch linked: lp:~ci-train-bot/gnome-control-center-signon/gnome- control-center-signon-ubuntu-xenial-landing-062 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Committed Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Confirmed Status in gnome-control-center-signon source package in Xenial: Confirmed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Also affects: gnome-control-center-signon (Ubuntu Yakkety) Importance: Critical Status: Fix Released ** Also affects: account-plugins (Ubuntu Yakkety) Importance: Critical Status: Fix Released ** Changed in: gnome-control-center-signon (Ubuntu Yakkety) Milestone: ubuntu-16.04.1 => None ** Changed in: account-plugins (Ubuntu Xenial) Milestone: None => ubuntu-16.04.1 ** Changed in: gnome-control-center-signon (Ubuntu Xenial) Milestone: None => ubuntu-16.04.1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Committed Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Confirmed Status in gnome-control-center-signon source package in Xenial: Confirmed Status in account-plugins source package in Yakkety: Fix Released Status in gnome-control-center-signon source package in Yakkety: Fix Released Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Changed in: gnome-control-center-signon (Ubuntu) Milestone: None => ubuntu-16.04.1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Committed Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Confirmed Status in gnome-control-center-signon source package in Xenial: Confirmed Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1565772] Re: [SRU] Allow plugins to decide which username to set on new accounts
** Summary changed: - Allow plugins to decide which username to set on new accounts + [SRU] Allow plugins to decide which username to set on new accounts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1565772 Title: [SRU] Allow plugins to decide which username to set on new accounts Status in Online Accounts: Account plugins: Fix Released Status in Canonical System Image: Fix Committed Status in Online Accounts: GNOME Control Center: Fix Released Status in webapps-sprint: Fix Committed Status in account-plugins package in Ubuntu: Fix Released Status in gnome-control-center-signon package in Ubuntu: Fix Released Status in account-plugins source package in Xenial: Confirmed Status in gnome-control-center-signon source package in Xenial: Confirmed Bug description: This bug is related to bug 1547647, even though it makes sense in any case. Currently, the ApOAuthPlugin class in libaccount-plugin gets the username from the SignonIdentity, which in turn gets it from signon- ui, which in the current WebKit1 implementation gets it from the DOM of the login webpage. This is a hack, it's fragile, not trivial to port to the Oxide web engine, and possibly against some providers' guidelines. We should retrieve the username using some REST API provided by the service, and in order to do so we need to extend libaccounts-plugin with some hooks which subclasses can use to get the username. Once we fix this we can also get rid of the files /etc/signon-ui /webkit-options.d/, which are conflicting with those installed by the KDE account plugins packages. SRU information === [Impact] The same file /etc/signon-ui/webkit- options.d/www.facebook.com.conf is installed by the account-plugin- facebook package (used by Unity) and by kaccount-providers (used by KDE). See this bug's duplicates to see actual bug reports. [Test Case] Install both account-plugin-facebook and kaccount- providers and you'll get the conflict. [Regression Potential] Users running KDE will be completely unaffected by this. Users running Unity might see a change when creating accounts in System Settings->Online Accounts: with this bugfix, the account's display name is obtained by making a REST API call to the remote service, rather than by scrapping the DOM of the server webpages (which is a hack, and prone to errors if the providers' webpage changes). The new way of retrieving the username is the proper one, and it's been tested to work reliably. In any case, the worst thing that might happen is that accounts get created with an empty display name, which is mostly an aesthetic problem (the display name is used only for UI purposes). To manage notifications about this bug go to: https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp