Kees Cook wrote:
>> /etc/service/status.d
>>
>> And if one exists for the job name, run it, otherwise just run the
>> upstart status and provide an LSB compatible return code.
>>
>> This would also allow for the post-start stanza to call the same code if
>> it is needed.
>>
>> Does anyone have stro
Correction, the meeting is at Thursday at 15:00 UTC instead of 13:00
UTC. I forgot to update the time when I changed the template, and
apologize for any confusion.
Michael
On Wed, Dec 15, 2010 at 3:28 PM, Michael Casadevall
wrote:
> Hi,
>
> Every Thursday at 13:00 UTC.
>
> We'll be havin
Hi,
Every Thursday at 13:00 UTC.
We'll be having the usual IRC meeting on #ubuntu-meeting, on
Thursday 2010-29-11 at 13:00 UTC. Please note that due to a
general resolution, the meeting day has been changed from
Tuesday to Thursday.
The new meeting page for this weeks meeting is at:
h
Hi,
On Wed, Dec 15, 2010 at 12:39:50PM -0800, Clint Byrum wrote:
> One thought that Dustin Kirkland had was to ehnance the 'service'
> command to look in a directory for shell snippets, something like
>
> /etc/service/status.d
>
> And if one exists for the job name, run it, otherwise just run th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 15 Dec 2010 14:23:00 -0500 (EST)
nuk...@aol.com wrote:
> Chuck:
> How much space will it take on my hard drive?
> This will help me determine which computer to use.
> Regards,
> Fabrizio Balsaq
>
Bzr took about 20MB and the documentation t
So during our discussion of upstart server enhancements at UDS-Natty[1],
one point of contention was whether the 'status' argument to init.d
scripts is important, and if so, where to put it.
For init scripts, LSB states:
The start, stop, restart, force-reload, and status actions shall
Am Mittwoch, den 15.12.2010, 20:59 +0100 schrieb Sebastien Bacher:
> - the is no easy way to get merge requests out of the queue, often "Need
> Works" is not available as an option and there is no team to
> unsubscribe, how do we mark than those need an update?
I think we should split the sponsors
On Wed, Dec 15, 2010 at 11:59 AM, Sebastien Bacher wrote:
> - bugs with a merge request are often listed twice (once for the bugs,
> once for the merge request). Not sure what the best way to avoid those
> duplication is, I've unsubscribed the ubuntu-sponsors from some bugs
> since reviews where b
On mer., 2010-12-15 at 15:20 +0100, Matthias Klose wrote:
> I can't find any reference that pre-promotions were allowed in the
> first place.
Those discussion happened on IRC last cycle
--
Sebastien Bacher
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscrib
Hey everybody,
Just dumping my first patch pilot notes for those interested ;-)
* bug #689741: reviewed the gtk patch attached and the upstream bug,
backported the git commit corresponding to the bug (different fix) to
natty
* bug #683076: pidgin sru to fix icq on lucid, unsubscribed the sponsor
On mer., 2010-12-15 at 13:22 +0100, Matthias Klose wrote:
> The current practice doesn't work
The question would rather to be "how we fix the mir issue so there is no
need to use pre-promoting". We started doing pre-promotions last cycle
because the mir team was overworked and said to pre-promote
On Wednesday, December 15, 2010 07:22:37 am Matthias Klose wrote:
> - pre-promote a package, submit a MIR "this looks easy" and leave the
> report alone to rot.
>
> - pre-promote a package, submit a MIR, get feedback from the MIR team
> "does the daemon run as root?" setting the report
On 15.12.2010 13:40, Jonathan Riddell wrote:
> On 15 December 2010 12:22, Matthias Klose wrote:
>> "pre-promoting" packages is a practice moving a package from universe to main
>> without review. please stop it! It may save the promoter a few hours, but it
>> adds to the workload of others, and un
On 15 December 2010 12:22, Matthias Klose wrote:
> "pre-promoting" packages is a practice moving a package from universe to main
> without review. please stop it! It may save the promoter a few hours, but it
> adds to the workload of others, and undermines security, QA and the MIR
> process
> (I
"pre-promoting" packages is a practice moving a package from universe to main
without review. please stop it! It may save the promoter a few hours, but it
adds to the workload of others, and undermines security, QA and the MIR process
(I have hardly seen a completed MIR for a pre-promoted packag
15 matches
Mail list logo
