Bluetooth: start every time. If I want it off, I set it off every boot. Why
I need to do that ?
On Fri, Nov 23, 2012 at 4:54 PM, Sebastien Bacher wrote:
> Le 23/11/2012 15:50, Dmitrijs Ledkovs a écrit :
>
> That means we will have to distinguish the case where we have both
>> autostart deskto
On 23 November 2012 15:26, Anca Emanuel wrote:
> Bluetooth: start every time. If I want it off, I set it off every boot. Why
> I need to do that ?
>
Currently in my session bluetoothd & bluetooth-applet are running,
even though bluetooth is hardware disabled.
You want bluetooth to start when the
On 23 November 2012 14:54, Sebastien Bacher wrote:
>
> Le 23/11/2012 15:50, Dmitrijs Ledkovs a écrit :
>
>> That means we will have to distinguish the case where we have both
>> autostart desktop file & upstart job file in the upstart-managed session.
>> (e.g. gwibber shipping both).
>> This migra
Le 23/11/2012 15:50, Dmitrijs Ledkovs a écrit :
That means we will have to distinguish the case where we have both
autostart desktop file & upstart job file in the upstart-managed
session. (e.g. gwibber shipping both).
This migration is very similar to how we currently support both
upstart jobs
On 23 November 2012 13:50, Sebastien Bacher wrote:
> Le 22/11/2012 14:02, Dmitrijs Ledkovs a écrit :
>
> Strangely enough, currently on my system I have:
> XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
>
> Why is it strange? We do add "xdg-" to the list to allow specific
> entries for flavors which
Le 22/11/2012 14:02, Dmitrijs Ledkovs a écrit :
Strangely enough, currently on my system I have:
XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
Why is it strange? We do add "xdg-" to the list to allow
specific entries for flavors which need those
There already is $XDG_CONFIG_DIRS/autostart and
On 22 November 2012 11:11, James Hunt wrote:
> Hi Robie,
>
> On 22/11/12 10:24, Robie Basak wrote:
>> A minor point, speaking as an uninformed observer.
>>
>>> /etc/xdg/init
>>
>> These files will be Upstart-specific, right? What if XDG want to use
>> /etc/xdg/init in the future? Would /etc/xdg/up
James,
On Thu, Nov 22, 2012 at 11:11:42AM +, James Hunt wrote:
> Agreed. I've changed the spec to reference /etc/xdg/upstart/ although
> I wonder if we should make this /etc/xdg/upstart/user/ (*) to make it
> clear the common jobs in that directory are only for Upstart running
> as a non-priv
A minor point, speaking as an uninformed observer.
> /etc/xdg/init
These files will be Upstart-specific, right? What if XDG want to use
/etc/xdg/init in the future? Would /etc/xdg/upstart avoid a potential
future namespace collision here?
I understand that /etc/xdg/init would be analogous to /et
Hi Robie,
On 22/11/12 10:24, Robie Basak wrote:
> A minor point, speaking as an uninformed observer.
>
>> /etc/xdg/init
>
> These files will be Upstart-specific, right? What if XDG want to use
> /etc/xdg/init in the future? Would /etc/xdg/upstart avoid a potential
> future namespace collision he
On 12-11-21 12:41 PM, Phillip Susi wrote:
> What sort of services are started right now but aren't necessarily
> required?
Gwibber-service is often trotted out as an example of a long-running
process that is highly inefficient and sucks up a lot of RAM while it is
operating.
The new friends-s
[including upstart-devel and ubuntu-devel both on this thread, instead of
having two separate discussions.]
On Tue, Nov 20, 2012 at 10:18:50AM -0800, Kees Cook wrote:
> >> This would mean user jobs would not be able to react to system job
> >> events. That in itself might not be a problem [1], b
On 11/21/2012 01:41 PM, Phillip Susi wrote:
> On 11/20/2012 5:09 AM, James Hunt wrote:
>> Here is the draft plan for 'Enhanced Upstart User Sessions' ([1]),
>> which will be used to supervise desktop sessions in Ubuntu:
>
>> https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2012 5:09 AM, James Hunt wrote:
> Here is the draft plan for 'Enhanced Upstart User Sessions' ([1]),
> which will be used to supervise desktop sessions in Ubuntu:
>
> https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions
>
>
James Hunt [2012-11-20 15:54 +]:
> This would mean user jobs would not be able to react to system job events.
Indeed that would make them a lot less useful. A major reason for
considering this in the first place is to make the startup of services
more dynamic, so if you can't react to hardware
Original Message
Subject: Re: Enhanced Upstart User Sessions for the Raring desktop
Date: Tue, 20 Nov 2012 15:53:40 +
From: James Hunt
Reply-To: james.h...@ubuntu.com
To: Evan Huus
CC: Upstart Devel List , ja...@ubuntu.com,
Kees Cook
Hi Evan,
On 20/11/12 13:58, Evan
Here is the draft plan for 'Enhanced Upstart User Sessions' ([1]), which will be
used to supervise desktop sessions in Ubuntu:
https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions
= Summary =
Allow Upstart to run as a non-privileged user to supervise a session in an
event-base
17 matches
Mail list logo
