Re: Two line init.d scripts? Sure, that will work!

Hi Petter, On Mittwoch, 5. Februar 2014, Petter Reinholdtsen wrote: [...] > As for the line counting in the subject, I decided to ignore commented > lines. Including those, we end up on 11 lines. :) I think this illustrates nicely the problem with this approach: - there are two lines, which con

Re: amd64 arch and optimization flags?

2014-02-06 Julian Taylor : > On 06.02.2014 00:39, Jaromír Mikeš wrote: > > > I would like to add some optimization flags for amd64 arch in some > > packages (mostly LV2 nad LADSPA plugins). > > I found these as candidates for amd64 arch: > > > > -msse > > -msse2 > > -mfpmath=sse > > this is enable

Re: amd64 arch and optimization flags?

On 06/02/2014 10:22, Jaromír Mikeš wrote: > > > > 2014-02-06 Julian Taylor >: > > On 06.02.2014 00:39, Jaromír Mikeš wrote: > > > I would like to add some optimization flags for amd64 arch in some > > packages (mostly LV2 nad LADSPA plugins). >

Re: amd64 arch and optimization flags?

2014-02-06 Sylvestre Ledru : > On 06/02/2014 10:22, Jaromír Mikeš wrote: > > 2014-02-06 Julian Taylor : > >> On 06.02.2014 00:39, Jaromír Mikeš wrote: >> >> > I would like to add some optimization flags for amd64 arch in some >> > packages (mostly LV2 nad LADSPA plugins). >> > I found these as ca

Re: amd64 arch and optimization flags?

]] Jaromír Mikeš > Aha ... so these default flags are added by compiler and they are not > controlled by debian tools at all? > Can I see somewhere default flags for different archs? run gcc -dumpspecs on the different platforms and you can see them. -- Tollef Fog Heen UNIX is user friendly, i

Re: Two line init.d scripts? Sure, that will work!

Hi Pere, On Wed, Feb 05, 2014 at 10:31:09PM +0100, Petter Reinholdtsen wrote: > The idea is to let init.d scripts look like this: > > #!/lib/init/init-d-script > ### BEGIN INIT INFO > # Provides: daemon > # Required-Start:$remote_fs $syslog > # Required-Stop: $remote_fs

Re: Two line init.d scripts? Sure, that will work!

> I think this illustrates nicely the problem with this approach: > - there are two lines, which contain code. > - there are five commented lines, which are interpreted and contain important > data. > - and there are four lines of commented code, which are mostly comments, > except two. And yet

Re: Two line init.d scripts? Sure, that will work!

On 02/06/2014 10:56, Helmut Grohne wrote: > The relevant bits can be found in insserv, watch out for > "/lib/init/upstart-job". The current version of insserv in unstable, 1.14.0-5, doesn't seem to contain this file. > It takes things one step further though. > Instead of having an interpreted sc

Re: Two line init.d scripts? Sure, that will work!

Quoting Petter Reinholdtsen (2014-02-05 22:31:09) > The idea is to let init.d scripts look like this: > > #!/lib/init/init-d-script > ### BEGIN INIT INFO > # Provides: daemon > # Required-Start:$remote_fs $syslog > # Required-Stop: $remote_fs $syslog > # Default-Start:

Re: Two line init.d scripts? Sure, that will work!

Petter Reinholdtsen writes: > The reason I bring this up on debian-devel@ is twofold. First, I want > to gather feedback on the idea. Will it work for your package, or are > some more hooks needed? With my syslog-ng upstream hat on: please, for the love of $deity, no! It's bad enough having to

Re: Two line init.d scripts? Sure, that will work!

[Helmut Grohne] > This idea has been brought up a fair number of times now. While others > have already pointed out, that this is basically the approach taken by > OpenRC, we have a very similar implementation in the archive for far > longer. It's called upstart! > > The relevant bits can be found

Re: Two line init.d scripts? Sure, that will work!

On 02/06/2014 05:31 AM, Petter Reinholdtsen wrote: > Hi. > > A few months ago I drafted an idea to rewrite init.d scripts to use a > common implementation and only specify the unique parts in the init.d > scripts themselves. That draft can be found on > http://people.skolelinux.org/pere/blog/Deb

Re: Two line init.d scripts? Sure, that will work!

On 02/06/2014 07:36 AM, Petter Reinholdtsen wrote: > [Russ Allbery] >> It's probably worth mentioning that this is basically the path down >> which OpenRC went, except that OpenRC has taken the concept somewhat >> further to allow the dependencies to be specified in code instead of >> comments (usi

Re: Two line init.d scripts? Sure, that will work!

On 02/06/2014 05:31 AM, Petter Reinholdtsen wrote: > Hi. > > A few months ago I drafted an idea to rewrite init.d scripts to use a > common implementation and only specify the unique parts in the init.d > scripts themselves. That draft can be found on > http://people.skolelinux.org/pere/blog/Deb

Bug#737830: ITP: belle-sip -- SIP stack from the Linphone team

Package: wnpp Severity: wishlist Owner: Felix Lechner * Package name: belle-sip Version : 1.2.4 Upstream Author : Jehan Monnier * URL : http://www.linphone.org/ * License : GPL2+, GPL3+, BSD, MIT, zlib Programming Lang: C and ANTLR Description : SIP st

Re: Two line init.d scripts? Sure, that will work!

[Thomas Goirand] >> Yeah, I discovered that OpenRC had a similar approach, but without >> staying compatible with our current set of scripts in /etc/init.d/. > > [1] Sorry... what?!? :) > > It's perfectly compatible. You just decide what you want to > (re-)implement or not. In fact, that's one of t

Re: Two line init.d scripts? Sure, that will work!

]] Petter Reinholdtsen > Ah, had completely forgotten about that script./lib/init/upstart-job. > Thank you for bringing it to my attention. Found the > /lib/init/upstart-job script in the upstart package and the code to > allow insserv to run '/etc/init.d/script lsb-header' to generate the > LSB

Re: Two line init.d scripts? Sure, that will work!

]] Thomas Goirand > Since last summer, OpenRC has full support for LSB headers. Also, I > believe that OpenRC is the only init system replacement which allows to > mix dependencies with LSB or it's own implementation. It's not, systemd has provided this from the start. -- Tollef Fog Heen UNIX

Re: Two line init.d scripts? Sure, that will work!

]] Petter Reinholdtsen > > Since last summer, OpenRC has full support for LSB headers. Also, I > > believe that OpenRC is the only init system replacement which allows > > to mix dependencies with LSB or it's own implementation. > > That is not the case. Both systemd and upstart allow this as w

Re: Two line init.d scripts? Sure, that will work!

[Thomas Goirand] > Well, you've been trying to reimplement OpenRC... with less > features! Don't bother, switch to OpenRC, and call it a day... :) Actually, I am trying to reduce code duplication in /etc/init.d/ while allowing package maintainers an easy way to stay compatible with systemd, upsta

Re: Two line init.d scripts? Sure, that will work!

[Sergey B Kirpichev] > Peter, thank you for your work. Have you tried any complex init > script to fit this business (apache2 or postfix, for example)? Nope. It is ment as an option for the packages with simple needs. Those with complex needs can use it too, probably, but it might be easier to j

Re: debconf managed configuration files

On 05/02/2014 10:42, Daniel Pocock wrote: > I've also found some references to the UCF package but it is not > referenced in the debconf-devel manpage itself, is UCF the way to go or > is this a red herring? If the default configuration file is shipped as-is by the package (no changes due to debco

Re: Two line init.d scripts? Sure, that will work!

Petter Reinholdtsen writes ("Two line init.d scripts? Sure, that will work!"): > A few months ago I drafted an idea to rewrite init.d scripts to use a > common implementation and only specify the unique parts in the init.d > scripts themselves. That draft can be found on > http://people.skolelin

Re: Two line init.d scripts? Sure, that will work!

Hi Ansgar, I am sorry to tell you that you are completely missing the point. On Thu, Feb 06, 2014 at 11:35:17AM +0100, Ansgar Burchardt wrote: > On 02/06/2014 10:56, Helmut Grohne wrote: > > The relevant bits can be found in insserv, watch out for > > "/lib/init/upstart-job". > > The current ver

Re: Re: Two line init.d scripts? Sure, that will work!

> Where can I read more about these problems. One obvious and annoying > one is that 'sh -x /etc/init.d/script start' no longer work, making it > harder to debug the scripts Probably init-d-script could pass some cli-specified options to sh with set builtin. To allow something like this: /etc/i

Re: Two line init.d scripts? Sure, that will work!

On Thu, Feb 06, 2014 at 11:47:24AM +0100, Petter Reinholdtsen wrote: > actions on services). Do I misunderstand how upstart-job work? If I > install a package with an upstart job and a symlink to > /lib/init/upstart-job from /etc/init.d/ on Hurd, will it work? > Testing... Nope, did not work: T

Re: Two line init.d scripts? Sure, that will work!

On 06/02/14 12:07, Helmut Grohne wrote: > This functionality is entirely orthogonal to the one I was proposing. > You are talking about redirecting the init script invocation to a > running systemd instance. I am talking about sysvinit (as pid 1) to > execute systemd .service descriptions. I'm sur

Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

Hi, There have been multiple new upstream releases for stunnel4 and the package has gathered quite some bugs without any feedback from its maintainer. Looking at Rodrigo's QA page [0] his last actions were quite some time ago (2012) and most packages would have gathered RC bugs without the help of

Re: Re: Two line init.d scripts? Sure, that will work!

>> Peter, thank you for your work. Have you tried any complex init >> script to fit this business (apache2 or postfix, for example)? > > Nope. It is ment as an option for the packages with simple needs. > Those with complex needs can use it too, probably, but it might be > easier to just keep the

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

On 02/06/2014 07:06 PM, Petter Reinholdtsen wrote: >> Since last summer, OpenRC has full support for LSB headers. Also, I >> believe that OpenRC is the only init system replacement which allows >> to mix dependencies with LSB or it's own implementation. > > That is not the case. Both systemd and

Re: amd64 arch and optimization flags?

On Thu, 06 Feb 2014 00:47:54 +0100, Julian Taylor wrote: > On 06.02.2014 00:39, Jaromír Mikeš wrote: >> >> Hi all, >> >> I would like to add some optimization flags for amd64 arch in some >> packages (mostly LV2 nad LADSPA plugins). >> I found these as candidates for amd64 arch: >> >> -msse -ms

Re: Two line init.d scripts? Sure, that will work!

On 02/06/2014 08:34 PM, Simon McVittie wrote: > it'll look rather similar to systemd; and by the time > you've sorted out circular dependencies, it'll have about the same level > of coupling between components as systemd. Why that? Dependency loops just have to be broken at run time when calculati

Re: Two line init.d scripts? Sure, that will work!

On Thu, Feb 06, 2014 at 12:34:49PM +, Simon McVittie wrote: > I'm sure we've been over this, on this very list, in several previous > threads. I used to think this was a great idea, too; I've been convinced > that it isn't feasible. Yes, I concur with the reasoning that I didn't quote here. In

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

]] Thomas Goirand > BTW, Debian has a way too many LSB header scripts with Required-Start: > $all, which is very bad. A decent init system has to deal with this, and > there's no sane way to do so but arbitrarily breaking what the author of > the script wrote. A lintian warning telling that $all

Re: Two line init.d scripts? Sure, that will work!

Petter Reinholdtsen wrote: > #!/lib/init/init-d-script > ### BEGIN INIT INFO > # Provides: daemon > # Required-Start:$remote_fs $syslog > # Required-Stop: $remote_fs $syslog > # Default-Start: 2 3 4 5 > # Default-Stop: 0 1 6 > # Short-Description: nice daem

please warn about "Required-Start: $all" in legacy init scripts

package: lintian severity: wishlist Hi, On Donnerstag, 6. Februar 2014, Thomas Goirand wrote: > BTW, Debian has a way too many LSB header scripts with Required-Start: > $all, which is very bad. A decent init system has to deal with this, and > there's no sane way to do so but arbitrarily breaking

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

> $all obviously (as you point out) doesn't work well. Semantically, it > doesn't make sense to have more than one script depending on $all. What I should use instead? Use case: http://packages.qa.debian.org/m/monit.html Usually, you want to start this service last and stop first. -- To UNSUBS

Bug#737867: please warn about "Required-Start: $all" in legacy init scripts

package: lintian severity: wishlist x-debbugs-cc: debian-devel@lists.debian.org,pkg-sysvinit-de...@lists.alioth.debian.org Hi, On Donnerstag, 6. Februar 2014, Thomas Goirand wrote: > BTW, Debian has a way too many LSB header scripts with Required-Start: > $all, which is very bad. A decent init s

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

]] Sergey B Kirpichev > > $all obviously (as you point out) doesn't work well. Semantically, it > > doesn't make sense to have more than one script depending on $all. > > What I should use instead? Use case: > http://packages.qa.debian.org/m/monit.html That's not a use case. > Usually, you wa

Re: debconf managed configuration files

On Wednesday 05 February 2014 10:42:23 Daniel Pocock wrote: > Has anybody written any further documentation about debconf with > configuration files, for example, for those that don't meet the > assumptions for the example in the debconf-devel manpage? > > Are there any particular packages that ar

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

>> Usually, you want to start this service last and stop first. > > Why should it start last? Because monit is not systemd. monit - is only an utility for proactive monitoring, not yet another init-replacement. So, lets start services first, then start monitoring. Do we want to play races with

Bug#737872: ITP: vim-snipmate -- Vim script that implements some of TextMate's snippets features.

Package: wnpp Severity: wishlist Owner: Andrea Capriotti * Package name: vim-snipmate Version : 0.84 Upstream Author : Michael Sanders * URL : http://www.vim.org/scripts/script.php?script_id=2540 * License : MIT Programming Lang: Vim Description : Vim

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

On 02/06/2014 10:59 PM, Sergey B Kirpichev wrote: >> $all obviously (as you point out) doesn't work well. Semantically, it >> doesn't make sense to have more than one script depending on $all. > > What I should use instead? Use case: > http://packages.qa.debian.org/m/monit.html > Usually, you wan

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

]] Sergey B Kirpichev > >> Usually, you want to start this service last and stop first. > > > > Why should it start last? > > Because monit is not systemd. monit - is only an utility for > proactive monitoring, not yet another init-replacement. > > So, lets start services first, then start mon

Re: Two line init.d scripts? Sure, that will work!

I'm sure there are more bits and pieces like those, that systemd services are free to rely on for (potentially major) simplifications. ...and IMHO it's the main systemd problem: it's too complex. :) And my personal opinion is that having implicit dependencies also isn't good... -- With best

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

> An init system that doesn't handle the case of something going «please > start $service» when it's already in the process of starting that > service, is buggy. It's not the problem, as all (most) debian's init-scripts use start-stop-daemon. The real problem - email notifications. You don't wan

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

]] Sergey B Kirpichev > Are you trying to sell me yet another init or do you suggest some > alternative solution *with* Debian's sysvinit, not using > "Should-Start/Stop: $all"? If the first, please stop. If > the second - please go ahead. No. I'm pointing out why $all doesn't do what you wan

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

On Thursday, February 06, 2014 13:59:59 Sebastian Reichel wrote: > Hi, > > There have been multiple new upstream releases for stunnel4 and the > package has gathered quite some bugs without any feedback from its > maintainer. Looking at Rodrigo's QA page [0] his last actions were > quite some time

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

Excerpts from Tollef Fog Heen's message of 2014-02-06 11:58:37 -0800: > ]] Sergey B Kirpichev > > > Are you trying to sell me yet another init or do you suggest some > > alternative solution *with* Debian's sysvinit, not using > > "Should-Start/Stop: $all"? If the first, please stop. If > > the

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

> I'm pointing out why $all doesn't do what you want. It's exactly what I want. > «$all» means «after everything else has started» and if you > have two of those You have a bug. Yes, some packages abuse $all, I admit this, but not all of them (e.g. monit). > In your particular case (and sysvin

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

On Thu, Feb 06, 2014 at 03:27:51PM -0500, Chris Knadle wrote: > On Thursday, February 06, 2014 13:59:59 Sebastian Reichel wrote: > [...] > > NMUs don't necessarily need to be minimalistic -- for instance packaging new > versions is something that can be done with NMUs. This is admittedly not > t

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

Adding Gregor Herrmann to this because he and I were looking to work on #672198 but we both were swamped with other work. On Friday, February 07, 2014 00:02:16 Sebastian Reichel wrote: > On Thu, Feb 06, 2014 at 03:27:51PM -0500, Chris Knadle wrote: > > On Thursday, February 06, 2014 13:59:59 Seba

Work-needing packages report for Feb 7, 2014

The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 512 (new: 11) Total number of packages offered up for adoption: 152 (new: 2) Total number of packages reques

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

On Thu, Feb 06, 2014 at 06:56:04PM -0500, Chris Knadle wrote: > I know; I agree with you and I think the text is a bit misleading -- by > stating that you shouldn't change the packaging style it seems to indicate > that NMUs are supposed to be minimalistic, but a situation in which the > maintai

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

Leaving off the MIA team on this reply, mainly because I don't think this is "news" to them per se and I'd rather not "spam" them. On Friday, February 07, 2014 02:54:09 Sebastian Reichel wrote: > On Thu, Feb 06, 2014 at 06:56:04PM -0500, Chris Knadle wrote: > > I know; I agree with you and I thin

Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

Hi all, In devscripts 2.13.3, uscan gained the ability to verify signature of the upstream tarball using a file debian/upstream-signing-key.pgp. In 2.14.0, I added the ability to use armored keys and decided to move the files under debian/upstream/, an idea which had been suggested by a few peopl

Re: Process spervision with Monit support in init systems (was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))

On 02/07/2014 03:58 AM, Tollef Fog Heen wrote: > ]] Sergey B Kirpichev > >> Are you trying to sell me yet another init or do you suggest some >> alternative solution *with* Debian's sysvinit, not using >> "Should-Start/Stop: $all"? If the first, please stop. If >> the second - please go ahead.

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

Another project that looks at DEP-12 metadata is DUCK, the Debian URL checker. I think it looks at DEP-12 stuff as a source of URLs to check. In your patch I think you mean [ ! -d $srcfile ] instead of -e? The latter will match if debian/upstream is a dir or a file but I think you want it to only

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

On Fri, Feb 07, 2014 at 01:18:09PM +0800, Paul Wise wrote: > Another project that looks at DEP-12 metadata is DUCK, the Debian URL > checker. I think it looks at DEP-12 stuff as a source of URLs to > check. From a quick glance, doesn't seem so. > In your patch I think you mean [ ! -d $srcfile ] i

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

Le Fri, Feb 07, 2014 at 12:41:51AM -0500, James McCoy a écrit : > On Fri, Feb 07, 2014 at 01:18:09PM +0800, Paul Wise wrote: > > > There are other issues with uscan/DEP-12; > > > > debian/watch is duplicated in the Watch field in DEP-12 debian/upstream. > > Partially. DEP-12 assumes it to be a