james wrote:
> On Wed, Oct 13, 2010 at 01:20:17PM +0200, Simon Schampijer wrote:
> > Ok, my point was that I do not have to unlink the files in Sugar,
> > since powerd takes care of that.
>
> It would be more efficient for the activity to unlink the files rather
> than leave the job to power
On Wed, Oct 13, 2010 at 01:20:17PM +0200, Simon Schampijer wrote:
> Ok, my point was that I do not have to unlink the files in Sugar,
> since powerd takes care of that.
It would be more efficient for the activity to unlink the files rather
than leave the job to powerd. The activity can know it ne
On 10/13/2010 12:14 PM, James Cameron wrote:
> On Wed, Oct 13, 2010 at 11:47:07AM +0200, Simon Schampijer wrote:
>> On 10/13/2010 12:29 AM, James Cameron wrote:
>>> On Tue, Oct 12, 2010 at 05:27:27PM +0200, Simon Schampijer wrote:
For 0.84 we can do what powerd offers, creating a file based on
On Wed, Oct 13, 2010 at 11:47:07AM +0200, Simon Schampijer wrote:
> On 10/13/2010 12:29 AM, James Cameron wrote:
> > On Tue, Oct 12, 2010 at 05:27:27PM +0200, Simon Schampijer wrote:
> >> For 0.84 we can do what powerd offers, creating a file based on the pid
> >> in /var/run/powerd-inhibit-suspend
On 10/13/2010 12:29 AM, James Cameron wrote:
> On Tue, Oct 12, 2010 at 05:27:27PM +0200, Simon Schampijer wrote:
>> For 0.84 we can do what powerd offers, creating a file based on the pid
>> in /var/run/powerd-inhibit-suspend/ (those are removed by powerd when it
>> goes into suspend the next time)
On Tue, Oct 12, 2010 at 10:21:12PM -0500, Mikus Grinbergs wrote:
> I was looking at the output of 'mount'. What's the difference between
> that and the output of 'cat /proc/mounts' ?
/etc/mtab is a file on the filesystem.
/proc/mounts is a query to the kernel.
When no arguments are given to mou
>> I believe that /var
>> itself is part of the / filesystem - that makes /var/run persistent.
>
> Odd, that doesn't match what I see in /proc/mounts ... there /var/run is
> a tmpfs of 1024k.
I was looking at the output of 'mount'. What's the difference between
that and the output of 'cat /proc/m
On Tue, Oct 12, 2010 at 06:08:27PM -0500, Mikus Grinbergs wrote:
> > We can rely on /var/run being empty on boot,
> > since it is a tmpfs.
>
> It is /var/tmp (and /var/log) that is a tmpfs. I believe that /var
> itself is part of the / filesystem - that makes /var/run persistent.
Odd, that doesn
> We can rely on /var/run being empty on boot,
> since it is a tmpfs.
It is /var/tmp (and /var/log) that is a tmpfs. I believe that /var
itself is part of the / filesystem - that makes /var/run persistent.
mikus
___
Devel mailing list
Devel@lists.lapt
On Tue, Oct 12, 2010 at 05:27:27PM +0200, Simon Schampijer wrote:
> For 0.84 we can do what powerd offers, creating a file based on the pid
> in /var/run/powerd-inhibit-suspend/ (those are removed by powerd when it
> goes into suspend the next time).
If I understand correctly, these are only rem
On 09/29/2010 08:31 AM, Tomeu Vizoso wrote:
> On Tue, Sep 28, 2010 at 21:43, Gonzalo Odiard wrote:
>> We have this code in many places, I found it in the Distance activity and
>> bitfrost updater.
>> May be is a good idea inhibit suspend when is displayed the neighborhood
>> view also.
>> Can we h
On Tue, Sep 28, 2010 at 21:43, Gonzalo Odiard wrote:
> We have this code in many places, I found it in the Distance activity and
> bitfrost updater.
> May be is a good idea inhibit suspend when is displayed the neighborhood
> view also.
> Can we have a unique class like PowerManager or anything li
We have this code in many places, I found it in the Distance activity and
bitfrost updater.
May be is a good idea inhibit suspend when is displayed the neighborhood
view also.
Can we have a unique class like PowerManager or anything like that?
Regards
Gonzalo
On Thu, Sep 16, 2010 at 8:23 PM, Jam
On 09/23/2010 03:55 PM, Tomeu Vizoso wrote:
> On Thu, Sep 23, 2010 at 15:30, Tomeu Vizoso wrote:
>> On Mon, Sep 20, 2010 at 12:56, Paul Fox wrote:
>>> tomeu wrote:
>>> > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>>> >wrote:
>>> > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu
>>> Viz
On Fri, Sep 24, 2010 at 09:12, Simon Schampijer wrote:
> On 09/23/2010 03:30 PM, Tomeu Vizoso wrote:
>> On Mon, Sep 20, 2010 at 12:56, Paul Fox wrote:
>>> tomeu wrote:
>>> > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>>> > wrote:
>>> > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu
>>>
On 09/23/2010 03:30 PM, Tomeu Vizoso wrote:
> On Mon, Sep 20, 2010 at 12:56, Paul Fox wrote:
>> tomeu wrote:
>> > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>> >wrote:
>> > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso
>> wrote:
>> > >> So the problem is that if you had to
On Thu, Sep 23, 2010 at 15:30, Tomeu Vizoso wrote:
> On Mon, Sep 20, 2010 at 12:56, Paul Fox wrote:
>> tomeu wrote:
>> > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>> > wrote:
>> > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso
>> wrote:
>> > >> So the problem is that if you had to re
On Mon, Sep 20, 2010 at 12:56, Paul Fox wrote:
> tomeu wrote:
> > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
> > wrote:
> > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso
> wrote:
> > >> So the problem is that if you had to resync all state for each machine
> > >> every time they wake
On Mon, Sep 20, 2010 at 12:56, Paul Fox wrote:
> tomeu wrote:
> > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
> > wrote:
> > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso
> wrote:
> > >> So the problem is that if you had to resync all state for each machine
> > >> every time they wake
tomeu wrote:
> On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
> wrote:
> > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso
> > wrote:
> >> So the problem is that if you had to resync all state for each machine
> >> every time they wake up, you would use lots of bandwidth with the
> > (...)
On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
wrote:
> On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso wrote:
>> So the problem is that if you had to resync all state for each machine
>> every time they wake up, you would use lots of bandwidth with the
> (...)
>> Another issue with this is that yo
On Thu, Sep 16, 2010 at 05:38:29PM -0400, Martin Langhoff wrote:
> 2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
> collaboration session is running
This might help. Once an activity is shared, the laptop stays awake
until the activity is stopped.
(sugar-toolkit.git)
--- a
On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso wrote:
> So the problem is that if you had to resync all state for each machine
> every time they wake up, you would use lots of bandwidth with the
(...)
> Another issue with this is that you not only want to resync presence,
> but shared activities al
On Thu, Sep 16, 2010 at 19:06, Richard A. Smith wrote:
> On 09/16/2010 05:05 AM, Tomeu Vizoso wrote:
>
>> So the problem is that if you had to resync all state for each machine
>> every time they wake up, you would use lots of bandwidth with the
>> power consumption associated, so much that it may
On 16 September 2010 10:05, Tomeu Vizoso wrote:
>> Is there any workaround we can apply -- seems like Salut or the much
>> maligned Presence Service has some regular event that re-syncs the nodes,
>> can we make it more often? (Sam suggested this earlier though I didn't
>> understand what he m
On 09/16/2010 05:05 AM, Tomeu Vizoso wrote:
> So the problem is that if you had to resync all state for each machine
> every time they wake up, you would use lots of bandwidth with the
> power consumption associated, so much that it may not have been worth
> sleeping.
Hmmm... /me has questions ab
On Thu, Sep 16, 2010 at 11:05, Tomeu Vizoso wrote:
> On Wed, Sep 15, 2010 at 18:50, Zarro Boogs per Child
> wrote:
>> #10363: Auto-Suspend gets in the way when sharing over Salut
>> ---+
>> Reporter: erikos
On Wed, Sep 15, 2010 at 18:50, Zarro Boogs per Child
wrote:
> #10363: Auto-Suspend gets in the way when sharing over Salut
> ---+
> Reporter: erikos | Owner: erikos
> Type: defect
28 matches
Mail list logo
