Ian Jackson writes:
> Well, no. I think that even if we select upstart as the default, we
> should enable the systemd community to provide as complete a set of
> integration in Debian as they care to put the work in for.
> That translates directly to an expectation that the maintainer of any
>
Steve Langasek wrote:
>On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
>> So unless the TC wants to remove a great number of packages from the
>> archive, you need to take into account the fact that some voluntary
>> manpower is required to implement your decision.
>
> I think th
Okay, let's see how replying to a mail on my phone while in flight mode
goes. Apologies in advance for formatting, quoting and vocabulary issues.
On Dec 31, 2013 4:48 AM, "Russ Allbery" wrote:
> 2. Impact of Multiple Init Systems
> Obviously, the ideal situation for project-wide integration and
On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote:
> Similarly, I'm not sure why the focus on only adding necessary tools to
> the initramfs image. Surely this doesn't matter much if the tools are
> harmless when unneeded?
In this context I'm not sure how applicable it is; but there ar
On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> Le mardi 31 décembre 2013 à 18:31 +, Ian Jackson a écrit :
> > Ansgar Burchardt writes ("Bug#727708: init system other points, and
> > conclusion"):
> > > What about the cgroup management functionality that newer versions of
>
Steve,
I am very sorry, I did not see the paragraph. I will familiarize myself
with the debate system before contributing to it again.
Happy New Years,
Cameron Norman
On Tue, Dec 31, 2013 at 6:21 PM, Steve Langasek
wrote:
On Wed, Jan 01, 2014 at 01:54:17AM -0008, cameron wrote:
I actuall
Le mercredi 01 janvier 2014 à 01:54 -0008, cameron a écrit :
> On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette
> wrote:
> > I am a bit confused here. You wrote in the upstart position
> > statement, almost at the top: “Upstart supports both bus activation
> > and socket activation.”
>
> I actua
On Wed, Jan 01, 2014 at 01:54:17AM -0008, cameron wrote:
> I actually added that to the statement. I did so because it has
> legitimate uses, and because it is something that a number of people
> have expressed interest in using.
Right, I never wrote that. I've reverted these changes to the posit
Josselin,
I actually added that to the statement. I did so because it has
legitimate uses, and because it is something that a number of people
have expressed interest in using.
Best regards,
Cameron Norman
On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette
wrote:
Le dimanche 29 décembre 201
Le dimanche 29 décembre 2013 à 22:50 -0800, Steve Langasek a écrit :
> Socket-based activation has never been a feature that upstart upstream has
> promoted the use of.
I am a bit confused here. You wrote in the upstart position statement,
almost at the top:
“Upstart supports both bus acti
Tollef Fog Heen writes:
> Given how the voting ratio so far looks, I've been giving the whole GR
> process a bit of thought lately and at least I am unlikely to pursue it,
> simply because I don't think it's a good way to spend my and the
> project's energy.
There's one point that I think is wor
On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
> Personally, I wish the TC was a bit more careful with the «people»
> angle of their rulings.
I'm personally very concerned about the developers whose decisions we
are overriding or mediating. But we probably don't convey this well
enough.
[...]
> and
First of all, thanks a lot for writing this mail. It expresses a lot of
my thoughts and feelings on the subject a lot more eloquently than I am
able to do myself. You're a wordsmith and a master of words. I am
not.
]] Russ Allbery
> Occasionally, there are decisions with sweeping consequence
]] Christoph Anton Mitterer
> On Tue, 2013-12-31 at 21:07 +0100, Tollef Fog Heen wrote:
> > That's handled by the initramfs where we currently don't use systemd.
> > (It's supported upstream to do so and we might eventually investigate
> > that, but I don't believe anybody has done any work on it
Hello all,
I did not see it linked yet, and thought it pertinent to the
discussion: some kde plasma desktop developers described their
possible intentions to utilize systemd functionality (while keeping
their existing shell script based startup for non systemd systems) in
a future release here
htt
On Mon, Dec 30, 2013 at 10:24 PM, Steve Langasek wrote:
> On Mon, Dec 30, 2013 at 08:12:19PM -0500, Michael Gilbert wrote:
>> > Part of my goal in writing up that plan was, as you
>> > say, to try to provide a means for people who are committed to one system
>> > or the other to continue to work on
On Tue, Dec 31, 2013 at 01:07:22PM -0800, Steve Langasek wrote:
> On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
> > Steve Langasek wrote:
> > > Looking more closely, I find that one of the conflicting files is a
> > > conffile
> > > (/etc/dbus-1/system.d/org.freedesktop.systemd1.c
Hello,
On Tue, 31 Dec 2013 13:07:22 -0800
Steve Langasek wrote:
> For the record, logind is not the only issue here. It's logind,
> timedated, hostnamed, localed which are needed by GNOME. This
> doesn't actually change the work involved in forking the package; but
> I think it would be ridicu
On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
> Steve Langasek wrote:
> > Looking more closely, I find that one of the conflicting files is a conffile
> > (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf). diversions and
> > conffiles still don't mix, AFAIK (and according to cu
Christoph Anton Mitterer writes:
> On Tue, 2013-12-31 at 11:15 -0800, Russ Allbery wrote:
>> For whatever it's worth, I've been using systemd on a system with LVM and
>> dm-crypt (with LUKS) for about a month now, in the dm-crypt -> LVM ->
>> filesystem mode, and haven't had any trouble.
> Do yo
Josselin Mouette writes:
> Which brings me to the other point: you are not going to decide what
> people want to spend their time on. If systemd is selected as the
> default, the systemd maintainers are not going to ask Steve to fix their
> upgrades problem for them. And if upstart is selected, y
On Tue, Dec 31, 2013 at 12:13 PM, Josselin Mouette
wrote:
Le mardi 31 décembre 2013 à 18:31 +, Ian Jackson a écrit :
Ansgar Burchardt writes ("Bug#727708: init system other points, and
conclusion"):
> What about the cgroup management functionality that newer
versions of
> logind requ
On Tue, 2013-12-31 at 21:07 +0100, Tollef Fog Heen wrote:
> That's handled by the initramfs where we currently don't use systemd.
> (It's supported upstream to do so and we might eventually investigate
> that, but I don't believe anybody has done any work on it for Debian.)
Sure... but
- using syst
On Tue, 2013-12-31 at 11:15 -0800, Russ Allbery wrote:
> For whatever it's worth, I've been using systemd on a system with LVM and
> dm-crypt (with LUKS) for about a month now, in the dm-crypt -> LVM ->
> filesystem mode, and haven't had any trouble.
Do you use it on your root-fs? With keyscripts?
]] Ian Jackson
> I think you have misunderstood. Or perhaps I hae misunderstood you.
> The "work" that I'm saying needs to be done anyway is the work to
> disentange the parts of systemd which are required by (say) GNOME from
> the parts which are only relevant for systemd as init.
>
> This is
Le mardi 31 décembre 2013 à 18:31 +, Ian Jackson a écrit :
> Ansgar Burchardt writes ("Bug#727708: init system other points, and
> conclusion"):
> > What about the cgroup management functionality that newer versions of
> > logind require? Should the systemd maintainers also reimplement it in
>
On Tue, Dec 31, 2013 at 10:31 AM, Ian Jackson
wrote:
Ansgar Burchardt writes ("Bug#727708: init system other points, and
conclusion"):
What about the cgroup management functionality that newer versions
of
logind require? Should the systemd maintainers also reimplement it
in
upstart?
This
]] Christoph Anton Mitterer
> Now that systemd could become default in Debian (well at least I favour
> it over upstream)... I started wondering how well it supports booting
> from a root fs on top of multiple block device layers?
That's handled by the initramfs where we currently don't use syst
]] Ian Jackson
> So I think we need to say what we regard as "reasonable" patches, in
> advance. As the Debian maintainer for uservd (for example), am I
> entitled to decline to incorporate systemd integration into my package
> on the grounds that the patch involves additional build- and runtime
Christoph Anton Mitterer writes:
> Right now there is a rather fixed order in which things work (i.e.
> phys->MD->LVM->dm-crypt->rootfs) out of the box (well in some cases at
> least) and IIRC, due to some "obscure" code in the cryptsetup initramfs
> scripts it works also with (dm-crypt->LVM)...
On Tue, Dec 31, 2013 at 08:44:15AM -0800, Russ Allbery wrote:
> > I'd like to suggest that this should only be done for daemons where
> > there is anything that a sysadmin can sensibly configure in this
> > way. The patch proposed for #712167 (native Upstart init support in
> > dbus) did this, but
On Tue, Dec 31, 2013 at 06:21:15PM +0100, Ansgar Burchardt wrote:
> And if upstart wants to use parts of systemd, why shouldn't the upstart
> maintainer do the work for this? Or they could fork logind which they
> suggested before... This would also allow having a newer systemd in
> Debian.
upstar
Michael Stapelberg writes:
> That being said, I just checked and realized the package is not
> available on non-linux. I’ll look into that now, since intuitively there
> is no reason for this.
Thank you, Michael. That would indeed make things much easier. I think
Ian is being excessively drama
Hi.
Now that systemd could become default in Debian (well at least I favour
it over upstream)... I started wondering how well it supports booting
from a root fs on top of multiple block device layers?
Some time ago I wrote [0] (with some contributions from others
AFAICS)...
So is there any infor
Hi Ian,
Ian Jackson writes:
>> > This is particularly the case for build-dependencies on an avowedly and
>> > intentionally non-portable program. Of course this can be made
>> > conditional, but this is IMO too fiddly.
>>
>> Adding [linux-any] to the Build-Depends line is not too fiddly, and if
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
> Ian Jackson writes:
> > For me it's a different proposition to suppose that _every_ daemon
> > should bring in these kind of dependencies.
>
> It's only going to be *every* daemon if we select systemd as the default
> init
Ansgar Burchardt writes ("Bug#727708: init system other points, and
conclusion"):
> What about the cgroup management functionality that newer versions of
> logind require? Should the systemd maintainers also reimplement it in
> upstart?
This is a somewhat separate issue, but: I think bundling the
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
>> These requirements, on the other hand, I find completely baffling.
>> This approach seems completely contrary to Debian best practices. Our
>> standard practice with all packages is to fully enable
Michael Gilbert writes ("Bug#727708: loose ends for init system decision"):
> On Mon, Dec 30, 2013 at 7:16 PM, Vincent Bernat wrote:
> > Unfortunately, being the best init is the not only the matter of its
> > maintainers. A good integration implies to modify some packages whose
> > maintainer may
Ian Jackson writes:
> intrigeri writes ("Bug#727708: init system other points, and conclusion"):
>> The difference lies in who are the people who "need" to do this work
>> "anyway", and who else may instead dedicate their time to other tasks,
>> lead by their own desires and needs.
>
> I think tha
intrigeri writes ("Bug#727708: init system other points, and conclusion"):
> (Sorry if I am duplicating a point that was already made.
> These threads are huge, and don't fit entirely into my memory.)
That's fine, of course.
> Ian Jackson wrote (30 Dec 2013 18:58:37 GMT) :
> > Unless you are prop
Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> On Mon, Dec 30, 2013 at 06:29:10PM +, Ian Jackson wrote:
> > This would be quite wrong; Replaces is not supposed to be used like
> > that (but you apparently know that).
>
> Yes. Raphaël rightly points out that dpkg-divert
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
> Ian Jackson writes:
> > - avoid extra build-dependencies (eg on libsystemd)
> > - avoid extra runtime dependencies (eg on deb-systemd-helper)
>
> These requirements, on the other hand, I find completely baffling.
>
> Thi
Simon McVittie writes:
> On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote:
>> The second supported option is DAEMON_OPTS, which sets additional flags
>> to add to the process. For as long as we need to support multiple init
>> systems, this option needs to stay in /etc/default/lbcd and
Package: wnpp
Owner: Dimitri John Ledkov
Severity: wishlist
* Package name: libnih.la
Version : 1.0.4 (git snapshot)
Upstream Author : Dimitri John Ledkov (DD), Scott James Remnant (DD)
* URL or Web page : https://github.com/xnox/libnih/tree/kfreebsd
http://libnih.la/
* License
Hello.
I'm writing to you to request to do not use no systemd, nor upstart.
I can guess that you have very important reasons to discuss this
possibilities, but…
IMHO, "systemd" doesn't even fit to UNIX philosophy [1].
[1] http://en.wikipedia.org/wiki/Unix_philosophy
Sorry if I'm wrong.
"upst
* Raphael Hertzog , 2013-12-30, 19:42:
dpkg-divert is the usual answer when you need/want to replace something
without the consent of the other side.
FWIW, Policy §3.9 reads:
“You should not use ‘dpkg-divert’ on a file belonging to another package
without consulting the maintainer of that pac
On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote:
> The second supported option is DAEMON_OPTS, which sets additional flags to
> add to the process. For as long as we need to support multiple init
> systems, this option needs to stay in /etc/default/lbcd and be read from
> there by all su
Steve Langasek wrote:
> Looking more closely, I find that one of the conflicting files is a conffile
> (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf). diversions and
> conffiles still don't mix, AFAIK (and according to current policy). So that
> seems to still leave us without a proper solu
On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson
wrote:
The criticisms of Upstart's event model in the systemd position
statement simply do not make sense to me. Events model how things
actually happen in reality; dependencies are artificial constructions
on
top of them, and making them work r
On Mon, Dec 30, 2013 at 09:52:37PM +0100, Tollef Fog Heen wrote:
> ]] Ian Jackson
> > Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> > > So I repeat here my request that the systemd maintainers make a suitable
> > > split of the systemd binary package, so that systemd-shim
]] Steve Langasek
> > In any case, systemd does indeed "support" this case; simply make your
> > service depend on network-online.target, which will block for a
> > reasonable amount of time to see if a network interface comes online,
> > and eventually time out if that doesn't occur. This will
On Mon, Dec 30, 2013 at 10:37:42PM -0800, Steve Langasek wrote:
> On Mon, Dec 30, 2013 at 09:58:07PM -0800, Josh Triplett wrote:
> > > But in the real world, we have a lot of services that we just want to
> > > start
> > > in runlevel 2 and be able to trust that the network and disk are sorted.
>
53 matches
Mail list logo
