Re: upstart: please update to latest upstream version

* Tollef Fog Heen [120223 22:21]: > ]] "Bernhard R. Link" > Your shell is most likely implemented in C, but it's not like you sit > down and have to debug it every other day. Why do you assume that you > need to do so just because policy is encoded in .ini-like files instead > of shell scripts?

Re: upstart: please update to latest upstream version

Le vendredi 24 février 2012 à 08:47 +0100, Bernhard R. Link a écrit : > What I try to say is "If there can only be one, then this should not > be systemd. So if Debian shall have systemd, it should support multiple > init systems." What we say is: there should be only one, and it will certainly n

Bug#661106: RFH: scim -- smart common input method platform

Package: wnpp Severity: normal I request assistance with maintaining the scim package. scim comprises software to input complex characters in non-latin languages such as Chinese Hanzi, Japanese Kanji or Korean Hangul and others. It enjoys widespread and growing use. scim is scheduled to be event

Re: upstart: please update to latest upstream version

On 02/23/2012 05:54 PM, Lars Wirzenius wrote: > On Thu, Feb 23, 2012 at 10:29:37AM +0100, Thomas Hood wrote: > >> I know the System V init system fairly well but I am new to both >> Upstart and systemd. Obviously the two are similar insofar as they are >> both able to supersede SysV init. >>

Bug#661110: RFH: isdnutils -- ISDN utilities

Package: wnpp Severity: normal (I hope reportbug will actually do the right thing, despite incorrectly claiming that isdnutils package did not exist) I am requesting assistance to maintain isdnutils in Debian. The main use case would be faxing, I assume. That's what I use the package for. But

Bug#661111: ITP: ffindex -- simple index/database for huge amounts of small files

Package: wnpp Severity: wishlist Owner: Laszlo Kajan * Package name: ffindex Version : 0.9.3 Upstream Author : Andreas Hauser * URL : http://pubshare.genzentrum.lmu.de/scientific_computing/software/ffindex/ * License : CC-BY-SA-3.0 Programming Lang: C Des

Re: upstart: please update to latest upstream version

Hi Martin, On Tue, Feb 21, 2012 at 01:06:41PM +0100, W. Martin Borgert wrote: > If I understand correctly, the current Ubuntu version 1.4-0ubuntu8 > works perfectly for Debian. Is there any reason to not upload this > version to Debian? The main reason is that there is as yet no solid policy that

Re: upstart: please update to latest upstream version

On Fri, 24 Feb 2012 17:07:46 +0800 Thomas Goirand wrote: > On 02/23/2012 05:54 PM, Lars Wirzenius wrote: > > On Thu, Feb 23, 2012 at 10:29:37AM +0100, Thomas Hood wrote: > > > >> I know the System V init system fairly well but I am new to both > >> Upstart and systemd. Obviously the two are si

Re: upstart: please update to latest upstream version

]] "Bernhard R. Link" > * Tollef Fog Heen [120223 22:21]: > > ]] "Bernhard R. Link" > > Your shell is most likely implemented in C, but it's not like you sit > > down and have to debug it every other day. Why do you assume that you > > need to do so just because policy is encoded in .ini-like f

Re: upstart: please update to latest upstream version

On Wed, Feb 22, 2012 at 03:24:47PM +0200, Riku Voipio wrote: > On Tue, Feb 21, 2012 at 01:12:08PM -0800, Steve Langasek wrote: > > The meme that systemd is better than upstart because it doesn't depend > > on a shell is poppycock. No one has done any benchmarking to support > > the claim that /bin

Re: upstart: please update to latest upstream version

On Fri, 2012-02-24 at 09:16 +0100, Josselin Mouette wrote: > Le vendredi 24 février 2012 à 08:47 +0100, Bernhard R. Link a écrit : > > What I try to say is "If there can only be one, then this should not > > be systemd. So if Debian shall have systemd, it should support multiple > > init systems."

Re: upstart: please update to latest upstream version

Svante Signell writes: > policy? While at the time supporting non-linux systems (like kFreeBSD > and Hurd, and others to come) I understood that Hurd does not use sysvinit either. Is that still the case? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsub

Bug#661114: ITP: python-ultramysql -- Fast MySQL library for Python

Package: wnpp Severity: wishlist Owner: Matthias Urlichs * Package name: python-ultramysql Version : 2.1 Upstream Author : Jonas Tarnstrom and ESN Social Software AB * URL : https://github.com/esnme/ultramysql * License : MIT/X Programming Lang: C++, Python

Re: upstart: please update to latest upstream version

On Fri, 2012-02-24 at 11:57 +0200, Timo Juhani Lindfors wrote: > Svante Signell writes: > > policy? While at the time supporting non-linux systems (like kFreeBSD > > and Hurd, and others to come) > > I understood that Hurd does not use sysvinit either. Is that still the > case? You are right, sy

Re: upstart: please update to latest upstream version

On 02/21/2012 11:22 PM, Steve Langasek wrote: > On Tue, Feb 21, 2012 at 10:28:55PM +0100, John Paul Adrian Glaubitz wrote: >>> What do you know of the upstart design that makes you think systemd's design >>> is better? The above could be a paraphrase of Lennart's blog, for all it >>> says about th

Re: upstart: please update to latest upstream version

On 02/22/2012 09:52 AM, Josselin Mouette wrote: > Le mardi 21 février 2012 à 23:37 +0100, John Paul Adrian Glaubitz a > écrit : >> The biggest disadvantage of systemd is surely that it is Linux-only and >> probably won't work with other kernels in near future, so it's absolutely >> desirable to su

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 10:51:23AM +0100, Svante Signell wrote: > On Fri, 2012-02-24 at 09:16 +0100, Josselin Mouette wrote: > > Le vendredi 24 février 2012 à 08:47 +0100, Bernhard R. Link a écrit : > > > What I try to say is "If there can only be one, then this should not > > > be systemd. So if

Re: upstart: please update to latest upstream version

Le vendredi 24 février 2012 à 10:45 +, Lars Wirzenius a écrit : > Should we allow kFreeBSD and Hurd (and, possibly, other kernels in > the future), which do not support the features required by systemd > and upstart, allow us to get away from sysvinit and start using an > event based init syst

Re: upstart: please update to latest upstream version

* Tollef Fog Heen [120224 10:45]: > ]] "Bernhard R. Link" > > * Tollef Fog Heen [120223 22:21]: > > > ]] "Bernhard R. Link" > > > Your shell is most likely implemented in C, but it's not like you sit > > > down and have to debug it every other day. Why do you assume that you > > > need to do so

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 10:45:41AM +, Lars Wirzenius wrote: > On Fri, Feb 24, 2012 at 10:51:23AM +0100, Svante Signell wrote: > > Then you are excluding all non-linux systems. Is that part of Debian > > policy? While at the time supporting non-linux systems (like kFreeBSD > > and Hurd, and othe

Re: upstart: please update to latest upstream version

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 24.02.2012 12:10, Josselin Mouette wrote: > There is another option here. We make a project-wide decision of > which init system to use for Linux (systemd or upstart). And we > write a compatibility layer for non-Linux systems, that generates >

Re: upstart: please update to latest upstream version

]] "Bernhard R. Link" > * Tollef Fog Heen [120224 10:45]: [...] > > systemd unit files are declarative. > > And that is exactly why I think you will likely need to be C programmer > and understand the internals of systemd to debug your boot process and > to fix it in case you have problems. H

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 9:10 AM, Josselin Mouette wrote: > Of course the hard part is to make the initial decision to switch to a > given init system; this is the kind of things Debian is very bad at. That's something I've always wondered. It seems to me that we'll *never* reach any form of conse

Re: upstart: please update to latest upstream version

* Tollef Fog Heen [120224 13:05]: > > And that is exactly why I think you will likely need to be C programmer > > and understand the internals of systemd to debug your boot process and > > to fix it in case you have problems. > > How do you come to that conclusion? It's not like you need to be a

Re: upstart: please update to latest upstream version

On Fri, 24 Feb 2012, Roger Leigh wrote: > There's nothing intrinsically non-portable about the systemd > socket-based activation scheme. It's just all the cgroups and other > stuff on top of that that's the problem. And the attitude of the > upstream maintainer towards portability. Has anyone i

Re: upstart: please update to latest upstream version

[Bernhard R. Link] > Currently we have a system where every user has a chance to debug > and fix those problems and make their system work again. I just wanted to give a small comment on this, as one of the sysvinit package maintainers in Debian. The quoted text give the impression that the curr

Re: Policy 3.9.3 released

On Thu, Feb 23, 2012 at 02:09:54PM -0800, Russ Allbery wrote: > > Does this have any influence on #658139? > > This particular change is unrelated. It just moved language from one > document to another; I've got this part. My question was targeting rather in the direction: Does the fact that th

Proposed removal of yiff

Hi, I plan to ask for the removal of the yiff sound package from Debian late next week. - It no longer appears to have any upstream maintainer. - The only package that depends on yiff is roaraudio, and I think that's only as a minor plugin. (I'm cc'ing the maintainers of roaraudio.) Pl

Re: Proposed removal of yiff

Am 24.02.2012 14:12, schrieb Phil Brooke: > Hi, > > I plan to ask for the removal of the yiff sound package from Debian late > next week. > - It no longer appears to have any upstream maintainer. > - The only package that depends on yiff is roaraudio, and I think that's > only as a minor p

Re: upstart: please update to latest upstream version

Roger Leigh wrote: > I certainly don't think it's fair for fairly niche platforms to hold > back Linux indefinitely. There is a high cost on maintainers to > support these platforms, and it would be an ideal situation if > systemd or upstart were sufficiently portable to run on them, even > if the

Re: upstart: please update to latest upstream version

On Fri, 2012-02-24 at 12:57 +0100, Arno Töll wrote: > Hi, > > On 24.02.2012 12:10, Josselin Mouette wrote: > > There is another option here. We make a project-wide decision of > > which init system to use for Linux (systemd or upstart). And we > > write a compatibility layer for non-Linux systems,

Re: upstart: please update to latest upstream version

m...@linux.it (Marco d'Itri) writes: > On Feb 23, Goswin von Brederlow wrote: > >> Say you have a desktop system but also have apache, postgresql, ... for >> some developement work installed. First thing you need when you turn it >> on is your desktop. The apache and postgresql do not need to be

Re: upstart: please update to latest upstream version

Salvo Tomaselli writes: >> But for me all the new init systems have a fundamental lack: They do not >> have priorities. > > I think that's gone already.. update-rc.d already does whatever it wants with > the priorities. Not what I ment. The traditional init doesn't have this either. MfG

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 11:31:38AM +1100, Russell Coker wrote: > Finally one benefit of an event based booting system is that it won't become > stuck if one daemon hangs. I've had problems in the past when one daemon > didn't start up and that prevented other daemons from starting due to the >

Re: upstart: please update to latest upstream version

Josselin Mouette writes: > Le vendredi 24 février 2012 à 10:45 +, Lars Wirzenius a écrit : >> Should we allow kFreeBSD and Hurd (and, possibly, other kernels in >> the future), which do not support the features required by systemd >> and upstart, allow us to get away from sysvinit and sta

Re: upstart: please update to latest upstream version

Petter Reinholdtsen writes: > [Bernhard R. Link] >> Currently we have a system where every user has a chance to debug >> and fix those problems and make their system work again. > > I just wanted to give a small comment on this, as one of the sysvinit > package maintainers in Debian. The quoted

Bug#661160: ITP: scirenderer -- Java rendering library based on JOGL

Package: wnpp Severity: wishlist Owner: Sylvestre Ledru * Package name: scirenderer Version : 0.3.3 Upstream Author : Pierre Lando (Digiteo) and other (Digiteo + Scilab Enterprises) * URL : http://forge.scilab.org/index.php/p/scirenderer/ * License : CeCILL

Re: upstart: please update to latest upstream version

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24.02.2012 17:07, Goswin von Brederlow wrote: > Josselin Mouette writes: And we write a > compatibility layer for non-Linux >> systems, that generates sysvinit-compatible scripts based on >> systemd services or upstart jobs. ... > So what you are s

Re: please advice: restrict architectures in advance or leave it alone?

Yaroslav Halchenko writes: > Hi, > > I am about to upload a fresh new package -- CDE > http://www.stanford.edu/~pgbovine/cde.html > which is heavily based on strace (pretty much it is a code fork of > strace to provide necessary functionality). > > Upstream author maintains it for x86 architectur

Re: Intent to file mass bugreports for ia32-libs*

Steve Langasek writes: > On Thu, Feb 23, 2012 at 12:13:33PM +0100, Goswin von Brederlow wrote: >> the goal for wheezy is to support multiarch and that means we can finaly >> get rid of the ugly ia32-libs packages. For this to happen all packages >> used in ia32-libs need to be multiarchified. > >

Re: please advice: restrict architectures in advance or leave it alone?

On Fri, 24 Feb 2012, Goswin von Brederlow wrote: > up, I would start disabling architectures. Since the package has never > been built on any architecture the build failures will not hold you back > in any way. All they do is generate build logs. ah -- I thought those FTBFS would forbid migration

Re: please advice: restrict architectures in advance or leave it alone?

Yaroslav Halchenko, le Fri 24 Feb 2012 12:00:00 -0500, a écrit : > On Fri, 24 Feb 2012, Goswin von Brederlow wrote: > > up, I would start disabling architectures. Since the package has never > > been built on any architecture the build failures will not hold you back > > in any way. All they do is

Re: A few observations about systemd

[ Sending this late reply now, which I had around as a draft, but with the latest incarnation of this debate it's become relevant again. ] Hi! On the "other kernels lack of features" I'll just point to the “Functionality Equivalence” section in the Porting Guidelines draft I've been preparing a

Re: upstart: please update to latest upstream version

On Thu, 2012-02-23 at 07:24:20 +0100, Tollef Fog Heen wrote: > ]] Tzafrir Cohen > > In sysv init scripts the daemon forks into the background. In upstrart > > and systemd it doesn't have to (or shouldn't). (not) forking requires a > > different command-line argument, normally. This leads to odd be

Re: upstart: please update to latest upstream version

[Goswin von Brederlow] > Not what I ment. The traditional init doesn't have this either. But sysvinit/startpar have it at the moment. The display managers have priority, and startpar try very hard to get them running early during the boot. :) If I remember correctly, the xdm, kdm and gdm scripts

Re: upstart: please update to latest upstream version

Steve Langasek writes: > On Tue, Feb 21, 2012 at 01:06:41PM +0100, W. Martin Borgert wrote: >> If I understand correctly, the current Ubuntu version 1.4-0ubuntu8 >> works perfectly for Debian. Is there any reason to not upload this >> version to Debian? > The main reason is that there is as yet

Re: upstart: please update to latest upstream version

"Bernhard R. Link" writes: > * Tollef Fog Heen [120224 13:05]: >> How do you come to that conclusion? It's not like you need to be a C >> programmer to debug CSS files or a C programmer to debug Makefiles. > As big a fan of Makefile that I am, but they are essentially > undebugable. Don't you

Re: upstart: please update to latest upstream version

Fernando Lemos writes: > Josselin Mouette wrote: >> Of course the hard part is to make the initial decision to switch to a >> given init system; this is the kind of things Debian is very bad at. > That's something I've always wondered. It seems to me that we'll *never* > reach any form of conse

Re: upstart: please update to latest upstream version

On Freitag, 24. Februar 2012, Karl Goetz wrote: > Contributors *to upstart* need to agree to the canonical contribution > agreement, I'm not sure what gives you the idea that all daemon > maintainers will fall in that category. still. a blocker. signature.asc Description: This is a digitally si

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 10:25:14AM -0800, Russ Allbery wrote: > Steve Langasek writes: > > On Tue, Feb 21, 2012 at 01:06:41PM +0100, W. Martin Borgert wrote: > >> If I understand correctly, the current Ubuntu version 1.4-0ubuntu8 > >> works perfectly for Debian. Is there any reason to not upload

Re: upstart: please update to latest upstream version

> On Freitag, 24. Februar 2012, Karl Goetz wrote: > > Contributors *to upstart* need to agree to the canonical contribution > > agreement, I'm not sure what gives you the idea that all daemon > > maintainers will fall in that category. [Holger Levsen] > still. > > a blocker. Eh, it's only a pro

Re: upstart: please update to latest upstream version

Peter Samuelson writes: > Eh, it's only a problem if the upstart maintainers in Debian refuse to > accept work (via either BTS patches, or done directly by comaintainers) > that upstream will not also accept. I don't really want Debian to be in the position of forking its own init system if we c

Re: upstart: please update to latest upstream version

On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote: > Upstart also does not support Should-Start which makes it impossible to > provide corect init scripts for a number of services. For example autofs > will not work if it uses nis because nis is not started before > autofs. Due

Re: A few observations about systemd

Guillem Jover wrote: > On the "other kernels lack of features" I'll just point to the > “Functionality Equivalence” section in the Porting Guidelines draft I've > been preparing at . > Most of the features listed as required for systemd are eith

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 12:50:15PM -0600, Peter Samuelson wrote: > > > On Freitag, 24. Februar 2012, Karl Goetz wrote: > > > Contributors *to upstart* need to agree to the canonical contribution > > > agreement, I'm not sure what gives you the idea that all daemon > > > maintainers will fall in th

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 05:02:25PM +0100, Goswin von Brederlow wrote: > On Fri, Feb 24, 2012 at 11:31:38AM +1100, Russell Coker wrote: > > Finally one benefit of an event based booting system is that it won't > > become > > stuck if one daemon hangs. I've had problems in the past when one daemon

Breaking the even playing field through CLAs (was: upstart: please update to latest upstream version)

Lars Wirzenius writes: > I see the following as a serious issue: upstart requires contributors > to sign the Canonical contributor agreement > (http://www.canonical.com/contributors). This is unlike most free-software projects, where “inbound = outbound” http://opensource.com/law/11/7/trouble-ha

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote: > Roger Leigh wrote: > > I certainly don't think it's fair for fairly niche platforms to hold > > back Linux indefinitely. There is a high cost on maintainers to > > support these platforms, and it would be an ideal situation if > > syst

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 20:17, Steve Langasek wrote: > On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote: > >> Upstart also does not support Should-Start which makes it impossible to >> provide corect init scripts for a number of services. For example autofs >> will not work if

Re: upstart: please update to latest upstream version

* Russ Allbery [120224 19:28]: > Staring at the bug and the makefile and thinking hard is usually sufficient. It's usually sufficient (because the concept is quite easy), but once that does not work there is hardly any other chance, except wild experimenting (which I hardly would like to do with

Re: upstart: please update to latest upstream version

"Bernhard R. Link" writes: > * Russ Allbery [120224 19:28]: >> One of the primary features of newer init systems like upstart and >> systemd is that they take care of the routine stuff automatically and >> thereby reduce the conceptual surface of your init script equivalent. >> Simpler things ar

Re: upstart: please update to latest upstream version

Roger Leigh wrote: > On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote: > > Portability is not necessarily a positive attribute. When you're talking > > about standard functionality available on all platforms, it's cleaner to > > write it using standard interfaces that work everywhere. Bu

Re: A few observations about systemd

On Fri, 2012-02-24 at 21:09 +0200, Uoti Urpala wrote: > Guillem Jover wrote: ... > I think it's quite arrogant of BSD users to expect others to work to > support their systems. The BSD userbase is small enough that most > projects have alternative things to work on that help a lot more people > tha

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 10:55:46PM +0100, Thomas Hood wrote: > On Fri, Feb 24, 2012 at 20:17, Steve Langasek wrote: > > On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote: > >> Upstart also does not support Should-Start which makes it impossible to > >> provide corect init scrip

Re: upstart: please update to latest upstream version

On Feb 25, 2012, at 12:42 AM, Steve Langasek wrote: > Well, I fudged a little here. You're right that, as written above, nis is > not guaranteed to start before autofs. Due to a (well-understood and > recognized) limitation of upstart's current event handling, if the > 'runlevel' event is seen

Re: upstart: please update to latest upstream version

On Fri, 2012-02-24 at 15:42 -0800, Steve Langasek wrote: > On Fri, Feb 24, 2012 at 10:55:46PM +0100, Thomas Hood wrote: > > On Fri, Feb 24, 2012 at 20:17, Steve Langasek wrote: > > > On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote: > > > >> Upstart also does not support Shoul

Re: upstart: please update to latest upstream version

Svante Signell writes: > Why not simply implement the early boot event driven parts in init as > proposed earlier, and get rid of these non-portable commercial stuff. > Are you really committed to Debian? Maybe you should work for Canonical > or RedHat? This sort of personal attack is neither ap

Re: New Free Software for 2D Animation

On Sat, Feb 25, 2012 at 8:41 AM, Nandakumar wrote: > The Chalanam 2D Animation Studio > https://launchpad.net/chalanam/ There doesn't appear to be any source code repository or tarballs. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debi

Bug#661208: ITP: mtbl -- immutable sorted string table library

Package: wnpp Severity: wishlist Owner: Robert S. Edmonds * Package name: mtbl Version : 0.1 Upstream Author : Internet Systems Consortium, Inc. * URL : https://github.com/edmonds/mtbl * License : ISC, BSD-3-Clause, Apache-2.0 Programming Lang: C Descriptio

Bug#661209: ITP: pymtbl -- immutable sorted string table library (Python bindings)

Package: wnpp Severity: wishlist Owner: Robert S. Edmonds * Package name: pymtbl Version : 0.1 Upstream Author : Internet Systems Consortium, Inc. * URL : https://github.com/edmonds/pymtbl * License : ISC Programming Lang: Cython Description : immutable

Re: upstart: please update to latest upstream version

On Sat, Feb 25, 2012 at 08:26:16AM +1100, Ben Finney wrote: > > I see the following as a serious issue: upstart requires contributors > > to sign the Canonical contributor agreement > > (http://www.canonical.com/contributors). > This is unlike most free-software projects, where “inbound = outboun

Re: upstart: please update to latest upstream version

Steve Langasek writes: > [1] Examples: MySQL as the "default" database for lots of projects; > Sleepycat/BDB as the backend for plenty of software, sometimes chosen > over GDBM; Qt; fox of ice and fire; and probably countless others that > don't come to mind because nobody really seemed to give t

Re: upstart: please update to latest upstream version

Hi Roger, On Fri, Feb 24, 2012 at 11:41:35AM +, Roger Leigh wrote: > Another alternative is to let sysvinit run systemd units and/or > upstart jobs. Given their declarative syntax, would it be possible > for these to be translated into init script form so that they can > be run by init? This

Re: upstart: please update to latest upstream version

Steve Langasek writes: > There are two main challenges here that I'm aware of with trying to > generate init scripts from upstart jobs: > - Process supervision. A lot of the win of moving to an init system like >upstart or systemd is that init *knows* which process corresponds to >whic

Re: upstart: please update to latest upstream version

On Fri, 2012-02-24 at 18:18 -0800, Steve Langasek wrote: > On Fri, Feb 24, 2012 at 07:58:21PM +, Ben Hutchings wrote: > > > Also, the only practical way this differs from the situation with > > > software from either the Free Software Foundation or the Apache > > > Software Foundation seems to

Re: upstart: please update to latest upstream version

On Sat, Feb 25, 2012 at 1:00 AM, Russ Allbery wrote: > Steve Langasek writes: > >> There are two main challenges here that I'm aware of with trying to >> generate init scripts from upstart jobs: > >>  - Process supervision.  A lot of the win of moving to an init system like >>    upstart or syste

Re: upstart: please update to latest upstream version

Fernando Lemos writes: > How about a converter from a different, init-agnostic format into the > specific formats? That way we could specify stuff that's specific to > each format, things such as: > * Socket activation information for systemd (and possibly upstart with > upstart-socket-bridge) >

Re: upstart: please update to latest upstream version

On Sat, Feb 25, 2012 at 1:35 AM, Fernando Lemos wrote: > * Socket activation information for systemd (and possibly upstart with > upstart-socket-bridge) By the way, I wonder if we could also come up with a wrapper that allowed upstart to work with the systemd socket activation protocol. If I'm no

Re: upstart: please update to latest upstream version

On Sat, Feb 25, 2012 at 1:44 AM, Russ Allbery wrote: >> This file could be easier to parse than a upstart/systemd unit too. I >> think even more than scripts could be converted into this basic >> format. The only drawback I can see is that it's another init >> description syntax to learn (if it's