I'm not able to reproduce the reported high CPU in indicator-datetime in
build 53.
Setup:
I took a phablet freshly flashed to build 53, ran phablet-click-test-setup on
the desktop followed by click-buddy --dir . --provision in the root
directories of ubuntu-clock-app and ubuntu-calendar-app.
On
We were able to reproduce the bug when the calendar and clock app were
not isolated when running the AP tests. However nskaggs's branch
attached to this bug report isolates the calendar app tests to its own
environment. That could probably be why you are not seeing the high CPU
usage. While
@nik90 , I'm finding that the autopilot tests are failing in trunk, this
is blocks Charles from investigating further:
Traceback (most recent call last):
File
/home/alesage/workspace/ubuntu-clock-app/tests/autopilot/ubuntu_clock_app/tests/test_clock.py,
line 95, in
Correction: these tests are working, thanks nik90 for your help getting
them running.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1321775
Title:
High CPU usage observed across EDS and
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qtorganizer5-eds (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1321775
** Branch linked: lp:~nskaggs/ubuntu-calendar-app/fix-ap-flo
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1321775
Title:
High CPU usage observed across EDS and indicator-datetime causing
clock
One interesting observation made today though: this happened once during
smoketesting, but we didn't notice any failures on system-settle after
the calendar-app tests. Normally when the CPU usage is really high (even
inbetween reboots) this should have been caught by system settle tests,
which
I'm not sure that I understand this report as it pertains to indicator-
datetime.
I'll rerun the steps above to see if I can reproduce and address the
high CPU load in indicator-datetime. However this seems like a red
herring to me for the problem described in the summary:
(1) indicator-datetime
@Charles,
[1] Clock and Calendar app *do not* run their AP tests in isolated EDS
sandboxes and that is the main issue. We already have a bug report in
the clock app requesting for mocking the EDS collection to avoid
interacting with the user's alarms and events, let alone the events of
another
@sil2100, I am not sure why the system settle tests are not failing. But
if the high CPU loads were observed manually and the tests dint fail,
then I suppose that would indicate the tests need to be modified/fixed
to detect these issue as a failure.
--
You received this bug notification because
10 matches
Mail list logo