image infrastructure knows about that and is designed never
to publish something that's bit for bit identical to something that's
already in the system.
As a result, build "4" for mako in daily may have:
- Ubuntu: 20130902
- Mako: 20130830
- Custom: 20130903.1
And, build "4
Hi guys,
On Wed, Sep 04, 2013 at 04:06:33PM +0100, John Lea wrote:
> Hi All, two questions about the proposal below:
> 1) How do we differentiate between background non-ui processes that
> are legitimately using 100%+ of the CPU for extended periods of time
> and runaway processes?
This is inde
Hello,
I'm the developer of Ubuntu Tasks, an application for the Ubuntu App
Showdown. I'd like to be display info graphics on the Ubuntu Phone welcome
screen, such as "2 Upcoming Tasks" or "1 Overdue Task". Is that currently
possible to do from a 3rd party app?
Thank you,
--
Michael Spencer | s
Hello,
I'm the developer of Ubuntu Tasks, an application for the Ubuntu App
Showdown. I'd like to be display info graphics on the Ubuntu Phone welcome
screen, such as "2 Upcoming Tasks" or "1 Overdue Task". Is that currently
possible to do from a 3rd party app?
Thank you,
--
Michael Spencer | so
Hi guys!
I am third party developer (as well as core app developer in RSS Reader
team), and I want to participate in
Ubuntu App Showdown (already participating to be strict).
My app uses qml extension plugin as well, can someone help me with
packaging?
Seems that currently there are no way to buil
On Wed, 2013-09-04 at 11:32 -0700, Steve Langasek wrote:
> On Wed, Sep 04, 2013 at 01:16:07PM -0500, Ted Gould wrote:
> > I wasn't intending to say "upstart should do it" more that we should put
> > it in the Upstart job configuration and use that as our basis. That's
> > what I was trying to say
On Wed, Sep 04, 2013 at 01:16:07PM -0500, Ted Gould wrote:
> > On Wed, Sep 04, 2013 at 10:22:59AM -0500, Ted Gould wrote:
> > > To give people something to attack more specifically, I'll say this. We
> > > should add a line to Upstart job configs that looks like this:
> > > cpu limit [CPU
On Wed, Sep 4, 2013 at 5:06 PM, John Lea wrote:
> Hi All, two questions about the proposal below:
>
> 1) How do we differentiate between background non-ui processes that are
> legitimately using 100%+ of the CPU for extended periods of time and runaway
> processes?
>
> e.g. We have a photo panora
On Wed, 2013-09-04 at 11:01 -0700, Steve Langasek wrote:
> On Wed, Sep 04, 2013 at 10:22:59AM -0500, Ted Gould wrote:
> > It seems to me for all of these long running services the "manager" of
> > them is Upstart. It restarts them if they crash or do other stupid
> > things, and it knows whether
On Wed, Sep 04, 2013 at 10:22:59AM -0500, Ted Gould wrote:
> It seems to me for all of these long running services the "manager" of
> them is Upstart. It restarts them if they crash or do other stupid
> things, and it knows whether they're running. This seems roughly like
> respawn limits[1], whe
On 4 September 2013 16:22, Ted Gould wrote:
> We should probably start with reporting bugs, and then next step start
> killing. "Would have been killed" bugs might be an interesting metric :-)
Just to be pedantic: send error reports, not file bugs. Bugs can most
certainly be created from a probl
On 09/04/2013 05:49 AM, Evan Dandrea wrote:
> Hi folks,
>
> In another discussion, James Hunt raised the possibility of
> periodically checking for runaway processes on Touch, killing those
> consuming 100% CPU while creating a report to be sent to
> https://errors.ubuntu.com.
>
> I've summarised
Hi Andrew,
very good point. I totally agree. Luckily we're doing better in other areas.
For example the Calendar component is already a shared one and there are
currently efforts ongoing for simple date and time pickers. So we are working
towards it.
This particular case is a little more tric
On 4 September 2013 12:25, Thomas Voß wrote:
> +1, the respective grace/timeout period would need to be determined
> from empirical data, too.
Agreed.
>> With the application lifecycle work, background applications will be
>> suspended and get no CPU time at all, so this check will only apply to
Hi All, two questions about the proposal below:
1) How do we differentiate between background non-ui processes that are
legitimately using 100%+ of the CPU for extended periods of time and
runaway processes?
e.g. We have a photo panorama app. After a set of photos are taken, the
camera app
Dmitrijs Ledkovs wrote:
>On 4 September 2013 12:09, Scott Kitterman
>wrote:
>> Dmitrijs Ledkovs wrote:
>> Changes like this should really be coordinated in Debian so we don't
>accumulate long term differences that can't easily be resolved.
>>
>
>Yeah, and as far as I know Timo is doing excellent
On 4 September 2013 14:07, Bálint Czobor wrote:
> Without this modification I can't initialize the repo, it says:
> Get git://phablet.ubuntu.com/git/CyanogenMod/android.git
> fatal: remote error: access denied or repository not exported:
> /git/CyanogenMod/android.git
> fatal: cannot obtain manife
On 04/09/13 16:06, John Lea wrote:
> Hi All, two questions about the proposal below:
>
> 1) How do we differentiate between background non-ui processes that are
> legitimately using 100%+ of the CPU for extended periods of time and
> runaway processes?
Good question. Most resources are bounded
On Wed, 2013-09-04 at 14:35 +0100, Evan Dandrea wrote:
> On 4 September 2013 12:25, Thomas Voß wrote:
> > +1, the respective grace/timeout period would need to be determined
> > from empirical data, too.
>
> Agreed.
I think that it should also be per-service. For instance, HUD does the
voice
Without this modification I can't initialize the repo, it says:
Get git://phablet.ubuntu.com/git/CyanogenMod/android.git
fatal: remote error: access denied or repository not exported:
/git/CyanogenMod/android.git
fatal: cannot obtain manifest git://
phablet.ubuntu.com/git/CyanogenMod/android.git
A
On Wed, Sep 4, 2013 at 2:04 PM, John Lenton wrote:
> On Wed, Sep 4, 2013 at 12:25 PM, Thomas Voß wrote:
>>
>> True, but to determine the CPU percentage, we would need to have the
>> CPU usage of all processes for a certain amount of time available.
>> That is, essentially parsing all of proc iiuc
On Wed, Sep 4, 2013 at 12:25 PM, Thomas Voß wrote:
>
> True, but to determine the CPU percentage, we would need to have the
> CPU usage of all processes for a certain amount of time available.
> That is, essentially parsing all of proc iiuc. I'm hopefully wrong,
> but if not, could we resort to an
On 4 September 2013 12:09, Scott Kitterman wrote:
> Dmitrijs Ledkovs wrote:
> Changes like this should really be coordinated in Debian so we don't
> accumulate long term differences that can't easily be resolved.
>
Yeah, and as far as I know Timo is doing excellent work at keeping
packaging in
hi,
On Mi, 2013-09-04 at 13:15 +0200, Alexander Sack wrote:
> > Note that this is not really about power consumption. Colin King has
> > done analysis of power consumption on Touch devices and the biggest
> > bang for the buck is ensuring that sensors are turned off when they
> > are not needed, n
Hey Evan,
thanks for the summary and for bringing up the topic. A few comments inline:
On Wed, Sep 4, 2013 at 11:49 AM, Evan Dandrea wrote:
> Hi folks,
>
> In another discussion, James Hunt raised the possibility of
> periodically checking for runaway processes on Touch, killing those
> consumin
On Wed, Sep 4, 2013 at 11:49 AM, Evan Dandrea wrote:
> Hi folks,
>
> In another discussion, James Hunt raised the possibility of
> periodically checking for runaway processes on Touch, killing those
> consuming 100% CPU while creating a report to be sent to
> https://errors.ubuntu.com.
>
> I've su
Dmitrijs Ledkovs wrote:
>So at the moment I have hacked up a way to cross compile qml extensions
>[1]
>The solution is not as fluid and packaging changes are needed in qt*
>packages to make all of this nicer.
>
>Foremost one cannot install ubuntu-sdk for multiple architectures:
>$ apt-get install
So at the moment I have hacked up a way to cross compile qml extensions [1]
The solution is not as fluid and packaging changes are needed in qt*
packages to make all of this nicer.
Foremost one cannot install ubuntu-sdk for multiple architectures:
$ apt-get install ubuntu-sdk ubuntu-sdk:armhf
Eve
Hi folks,
In another discussion, James Hunt raised the possibility of
periodically checking for runaway processes on Touch, killing those
consuming 100% CPU while creating a report to be sent to
https://errors.ubuntu.com.
I've summarised the key points of that discussion here into a
proposal. The
29 matches
Mail list logo
