This bug was fixed in the package unity8 - 8.00+14.10.20140822-0ubuntu1
---------------
unity8 (8.00+14.10.20140822-0ubuntu1) utopic; urgency=low
[ Albert Astals ]
* More stable dash overview tests
* PreviewExpandable: "widgets" is a model, not an array
[ Alberto Aguirre ]
* Proxy inactivity timeout values from gsettings into Unity.Screen
(LP: #1230345)
[ Gerry Boland ]
* Cancel open PAM interactions on shutdown - fixes hang on logout on
desktop (LP: #1353041)
[ Diego Sarmentero ]
* Show progress bar on payment button click The payment process has a
small delay before the UI comes up which might cause confusion. Show
a progress bar with unknown value to indicate activity. (LP:
#1354139)
[ Mirco Müller ]
* Made notification qml-test pass again by using Component.onCompleted
instead of onOpacityChanged for the time being.
[ Michael Zanetti ]
* Implement new lockscreen designs
[ Michael Terry ]
* Show the SIM unlock dialog immediately after booting, and enable its
emergency call button.
* Always keep indicator/launcher locked state in sync with whether the
user is authenticated. (LP:# 1357230) (LP: #1357230)
* Allow logging into a desktop or tablet session again, by properly
dismissing old PAM conversations. (LP: #1350878) In a desktop or
tablet, we were accidentally starting two PAM conversations in
sequence on startup. Which is a small bug; it shouldn't normally be
a problem, since each new PAM conversation should kill the old
one.But the way we were killing the old one was subject to a thread
race condition. See, a PAM conversation thread won't exit until all
its prompts are answered. And what we do when we kill a PAM
conversation is to answer all prompts with empty strings.But it's
possible that when we want to kill a PAM conversation that it hasn't
actually gotten to the point of prompting us yet. And when those
prompts do come through, we were treating them as prompts for the
new PAM conversation.So I've changed the PAM conversation logic to
include a pam_handle and compare the handle with the current handle
when being prompted. If it's an old handle, we just dismiss the
prompt with an empty string response.Oh, and I fixed the bug that
caused two prompts on startup in the first place. (But we still need
the above logic anyway, for when you switch users quickly.) (LP:
#1350878)
[ Martin Pitt ]
* Mark for using language packs.
-- Ubuntu daily release <ps-jenk...@lists.canonical.com> Fri, 22 Aug 2014
09:29:41 +0000
** Changed in: unity8 (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gsettings-ubuntu-touch-
schemas in Ubuntu.
https://bugs.launchpad.net/bugs/1230345
Title:
Unity8 should control the display "lock after idle" (with a way to
configure the delay)
Status in GSettings schemas for Ubuntu touch:
Fix Released
Status in Unity System Compositor:
Fix Released
Status in The Unity 8 shell:
In Progress
Status in “gsettings-ubuntu-touch-schemas” package in Ubuntu:
Fix Released
Status in “ubuntu-system-settings” package in Ubuntu:
Triaged
Status in “unity8” package in Ubuntu:
Fix Released
Bug description:
Currently powerd is doing that but apparently unity8 is going to take
over that.
Some questions:
- when is the work going to happen (before or after v1)
- is that going to be an unity8 configuration (user owned?)
- is it going to be stored in gsettings?
We need to know the answer the those questions to be able to do the
system-settings corresponding work...
Note that currently we write a powerd gsettings key, but that's buggy
since powerd is running as root and we write an user key. There is
also no way to write a system key on the ro image
Should we drop that setting for v1?
To manage notifications about this bug go to:
https://bugs.launchpad.net/gsettings-ubuntu-touch-schemas/+bug/1230345/+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
