Steve Langasek writes:
> For the TC decision, what kind of information are you looking for about
> the plans, beyond "the Ubuntu developers expect to need to address this
> before upgrading from systemd logind 204 and will hold at 204 until a
> correct solution is known"?
I think the right way t
Hi Russ,
On Tue, Oct 29, 2013 at 04:16:04PM -0700, Russ Allbery wrote:
> Therefore, I think it's important for arguments against using systemd to
> somehow engage directly with the questions about functionality. Either
> there needs to be an argument that the functionality is not important and
>
Processing commands for cont...@bugs.debian.org:
> reassign 728486 tech-ctte
Bug #728486 [debian-ctte] Determine how to handle incompatiblity between
systemd and lvm2
Warning: Unknown package 'debian-ctte'
Bug reassigned from package 'debian-ctte' to 'tech-ctte'.
Ignoring request to alter found v
On Fri, 01 Nov 2013 09:30:22 -0700
Russ Allbery wrote:
> I don't personally consider this a major issue
It's probably not something that cannot be worked around in some way,
as the upstart position statement asserts (which by the way I *have*
read).
However, IMHO systemd's cgroups solution make
On Fri, Nov 01, 2013 at 06:49:34PM +, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: Value of reading other's position
> statements [was: systemd vs. whatever]"):
> > I agree with all of the technical critiques here, I just don't see that this
> > relatively minor issue, which can be
Steve Langasek writes ("Bug#727708: Value of reading other's position
statements [was: systemd vs. whatever]"):
> I agree with all of the technical critiques here, I just don't see that this
> relatively minor issue, which can be documented and worked around (and
> ultimately, fixed upstream), is
On Fri, Nov 01, 2013 at 05:39:15PM +, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: Value of reading other's position
> statements [was: systemd vs. whatever]"):
> > I agree. It would still require some fiddling to make 'expect stop' work
> > together with strace anyway, since upst
Steve Langasek writes ("Bug#727708: Value of reading other's position
statements [was: systemd vs. whatever]"):
> I agree. It would still require some fiddling to make 'expect stop' work
> together with strace anyway, since upstart only cares about SIGSTOP raised
> by upstart's child process, not
On Fri, Nov 01, 2013 at 04:31:30PM +, Ian Jackson wrote:
> Miroslaw Baran writes ("Bug#727708: Value of reading other's position
> statements [was: systemd vs. whatever]"):
> > You wrote:
> > > One non-feature of upstart which I happen to care strongly about is its
> > > use of ptrace(2) to fi
Miroslaw Baran writes ("Bug#727708: Value of reading other's position
statements [was: systemd vs. whatever]"):
> You wrote:
> > One non-feature of upstart which I happen to care strongly about is its
> > use of ptrace(2) to figure out what a job is doing. This destroys any
> > attempt to just use
Miroslaw Baran writes:
> You wrote:
>> One non-feature of upstart which I happen to care strongly about is its
>> use of ptrace(2) to figure out what a job is doing. This destroys any
>> attempt to just use "strace foo" as the job, if one really needs to
>> figure out what a piece of software is
Dear Mr. Urlichs,
You wrote:
> One non-feature of upstart which I happen to care strongly about is its
> use of ptrace(2) to figure out what a job is doing. This destroys any
> attempt to just use "strace foo" as the job, if one really needs to
> figure out what a piece of software is doing wrong
IMHO.
Sorry, but SysV init scripts are an unfixable mess. The sooner we have
a system which does not have, let alone require, /etc/rc*, the better.
One non-feature of upstart which I happen to care strongly about is its
use of ptrace(2) to figure out what a job is doing. This destroys any
attempt
13 matches
Mail list logo
