Re: runit maintenance - Re: patch: sv check should wait when svrun is not ready

[Lasse Kliemann]

Avery Payne  writes:

>> I think the whole idea of "registered namespaces for software packages"
>> is a good idea and should be supported. There are of course different
>> ways of implementing it.

> Why not keep slashpackage as an "alternative" installation method? Is 
> there any reason you can't package both "traditional" and "slashpackage" 
> methods together?

Anything can be achieved by implementing additional levels of
indirection.

At the moment, I am just interested in whether people (especially people
on this list) believe there is something wrong with slashpackage, and if
so, what it is in particular.


signature.asc
Description: PGP signature

Re: runit maintenance - Re: patch: sv check should wait when svrun is not ready

[Avery Payne]

On 6/18/2015 6:24 PM, Buck Evan wrote:

Thanks Gerrit.

How would you like to see the layout, build process look? Maybe there's an
example project you like?
If it's easy enough for me to try, I'd like to.



I pulled Gerrit's stuff into bitbucket a few days ago.  The first step I 
would humbly suggest, would be to remove the tarballs embedded into the 
repository.Cleaning those out would reduce visual noise when looking 
at the file layout.  Because the entire source history is available, 
there is no reason you can't go back and recreate them on-demand; roll 
back the repo to a prior version and run a makefile outside of it to 
build a tarball.

Re: runit maintenance - Re: patch: sv check should wait when svrun is not ready

[Avery Payne]

On 6/20/2015 3:58 AM, Lasse Kliemann wrote:

Gerrit Pape  writes:


First is moving away from slashpackage.  Doing it similar to what
Laurant does in his current projects sounds good to me, but I didn't
look into details.  This even might include moving away from the djblib
(Public Domain files from daemontools included in runit) to skalibs.

Sorry to interrupt. Why moving away from slashpackage?

As far as I see, Laurent's build system is a super-set up slashpackage
functionality.

I think the whole idea of "registered namespaces for software packages"
is a good idea and should be supported. There are of course different
ways of implementing it.
Why not keep slashpackage as an "alternative" installation method? Is 
there any reason you can't package both "traditional" and "slashpackage" 
methods together?

Re: runit maintenance - Re: patch: sv check should wait when svrun is not ready

[Lasse Kliemann]

Gerrit Pape  writes:

> First is moving away from slashpackage.  Doing it similar to what
> Laurant does in his current projects sounds good to me, but I didn't
> look into details.  This even might include moving away from the djblib
> (Public Domain files from daemontools included in runit) to skalibs.

Sorry to interrupt. Why moving away from slashpackage?

As far as I see, Laurent's build system is a super-set up slashpackage
functionality.

I think the whole idea of "registered namespaces for software packages"
is a good idea and should be supported. There are of course different
ways of implementing it.


signature.asc
Description: PGP signature

Re: runit maintenance - Re: patch: sv check should wait when svrun is not ready

[Gerrit Pape]

On Thu, Jun 18, 2015 at 06:24:13PM -0700, Buck Evan wrote:
> How would you like to see the layout, build process look? Maybe there's an
> example project you like?
> If it's easy enough for me to try, I'd like to.

First is moving away from slashpackage.  Doing it similar to what
Laurant does in his current projects sounds good to me, but I didn't
look into details.  This even might include moving away from the djblib
(Public Domain files from daemontools included in runit) to skalibs.

Best, Gerrit.

Re: runit maintenance - Re: patch: sv check should wait when svrun is not ready

[Buck Evan]

It would be good if that URI appeared on the runit homepage:
http://smarden.org/git/runit.git

On Thu, Jun 18, 2015 at 6:24 PM, Buck Evan  wrote:

> Thanks Gerrit.
>
> How would you like to see the layout, build process look? Maybe there's an
> example project you like?
> If it's easy enough for me to try, I'd like to.
>
> On Thu, Jun 18, 2015 at 7:54 AM, Gerrit Pape  wrote:
>
>> Hi all,
>>
>> I'm around, but currently not very active in my open source activities.
>>
>> runit started in 2001 and was tracked in CVS.  After I took over Debian
>> maintainership of git in 2005, I converted the repository to git.  The
>> complete history is available since then
>>
>>  git clone http://smarden.org/git/runit.git/
>>
>> Every here and then I think about doing some work on runit, like
>> integrating patches, but find the file layout in the repo, the build and
>> installation process, so archaic that I stop again, most of the time.
>> It's about 13 years old..
>>
>> Those two things are the two top items on my TODO list.
>>
>> Regards, Gerrit.
>>
>>
>> On Thu, Jun 18, 2015 at 10:35:45AM +, James Byrne wrote:
>> > Similarly, I have two patches which I submitted to the mailing list in
>> February which I would like to get merged:
>> >
>> > http://www.mail-archive.com/supervision@list.skarnet.org/msg00500.html
>> >
>> > http://www.mail-archive.com/supervision@list.skarnet.org/msg00501.html
>> >
>> > It would be useful if Gerrit could respond to confirm whether he is
>> still accepting patches to runit or planning to do any future releases.
>> >
>> > Regards,
>> >
>> > James
>> >
>> > -Original Message-
>> > From: supervision@list.skarnet.org [mailto:supervision@list.skarnet.org]
>> On Behalf Of Avery Payne
>> > Sent: 16 June 2015 18:43
>> > To: Buck Evan
>> > Cc: supervision@list.skarnet.org
>> > Subject: Re: patch: sv check should wait when svrun is not ready
>> >
>> > I'm not the maintainer of any C code, anywhere.  While I do host a
>> mirror or two on bitbucket, I only do humble scripts, sorry.  Gerrit is
>> around, he's just a bit elusive.
>> >
>> > On 6/16/2015 9:37 AM, Buck Evan wrote:
>> > > I'd still like to get this merged.
>> > >
>> > > Avery: are you the current maintainer?
>> > > I haven't seen Gerrit Pape on the list.
>> > >
>> > > On Tue, Feb 17, 2015 at 4:49 PM, Buck Evan > > > > wrote:
>> > >
>> > > On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne
>> > > mailto:avery.p.pa...@gmail.com>> wrote:
>> > > >
>> > > > On 2/17/2015 11:02 AM, Buck Evan wrote:
>> > > >>
>> > > >> I think there's only three cases here:
>> > > >>
>> > > >>  1. Users that would have gotten immediate failure, and no
>> > > amount of
>> > > >> spinning would help. These users will see their error delayed
>> > > by $SVWAIT
>> > > >> seconds, but no other difference.
>> > > >>  2. Users that would have gotten immediate failure, but could
>> > > have gotten
>> > > >> a success within $SVWAIT seconds. All of these users will of
>> > > course be glad
>> > > >> of the change.
>> > > >>  3. Users that would not have gotten immediate failure. None of
>> > > these
>> > > >> users will see the slightest change in behavior.
>> > > >>
>> > > >> Do you have a particular scenario in mind when you mention
>> > > "breaking lots
>> > > >> of existing installations elsewhere due to a default behavior
>> > > change"? I
>> > > >> don't see that there is any case this change would break.
>> > > 
>> > >
>> > > Thanks for the thoughtful reply Avery. My background is also
>> > > "maintaining business software", although putting it in those
>> terms
>> > > gives me horrific visions of java servlets and soap protocols.
>> > >
>> > > > I have to look at it from a viewpoint of "what is everything
>> > > else in the system expecting when this code is called".  This
>> > > means thinking in terms of code-as-API, so that calls elsewhere
>> > > don't break.
>> > >
>> > > As a matter of API, sv-check does sometimes take up to $SVWAIT
>> > > seconds to fail.
>> > > Any caller to sv-check will be expecting this (strictly limited)
>> > > delay, in the exceptional case.
>> > > My patch just extends this existing, documented behavior to the
>> > > special case of "unable to open supervise/ok".
>> > > The API is unchanged, just the amount of time to return the result
>> > > is changed.
>> > >
>> > > > This happens because the use of "sv check (child)" follows the
>> > > convention of "check, and either succeed fast or fail fast", ...
>> > >
>> > > Either you're confused about what sv-check does, or I'm confused
>> about
>> > > what you're saying.
>> > > sv-check generaly doesn't fail fast (except in the special case
>> I'm
>> > > trying to make no longer fail fast -- svrun is not started).
>> > > Generally it will spin for $SVWAIT seconds before fail

Re: runit maintenance - Re: patch: sv check should wait when svrun is not ready

[Buck Evan]

Thanks Gerrit.

How would you like to see the layout, build process look? Maybe there's an
example project you like?
If it's easy enough for me to try, I'd like to.

On Thu, Jun 18, 2015 at 7:54 AM, Gerrit Pape  wrote:

> Hi all,
>
> I'm around, but currently not very active in my open source activities.
>
> runit started in 2001 and was tracked in CVS.  After I took over Debian
> maintainership of git in 2005, I converted the repository to git.  The
> complete history is available since then
>
>  git clone http://smarden.org/git/runit.git/
>
> Every here and then I think about doing some work on runit, like
> integrating patches, but find the file layout in the repo, the build and
> installation process, so archaic that I stop again, most of the time.
> It's about 13 years old..
>
> Those two things are the two top items on my TODO list.
>
> Regards, Gerrit.
>
>
> On Thu, Jun 18, 2015 at 10:35:45AM +, James Byrne wrote:
> > Similarly, I have two patches which I submitted to the mailing list in
> February which I would like to get merged:
> >
> > http://www.mail-archive.com/supervision@list.skarnet.org/msg00500.html
> >
> > http://www.mail-archive.com/supervision@list.skarnet.org/msg00501.html
> >
> > It would be useful if Gerrit could respond to confirm whether he is
> still accepting patches to runit or planning to do any future releases.
> >
> > Regards,
> >
> > James
> >
> > -Original Message-
> > From: supervision@list.skarnet.org [mailto:supervision@list.skarnet.org]
> On Behalf Of Avery Payne
> > Sent: 16 June 2015 18:43
> > To: Buck Evan
> > Cc: supervision@list.skarnet.org
> > Subject: Re: patch: sv check should wait when svrun is not ready
> >
> > I'm not the maintainer of any C code, anywhere.  While I do host a
> mirror or two on bitbucket, I only do humble scripts, sorry.  Gerrit is
> around, he's just a bit elusive.
> >
> > On 6/16/2015 9:37 AM, Buck Evan wrote:
> > > I'd still like to get this merged.
> > >
> > > Avery: are you the current maintainer?
> > > I haven't seen Gerrit Pape on the list.
> > >
> > > On Tue, Feb 17, 2015 at 4:49 PM, Buck Evan  > > > wrote:
> > >
> > > On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne
> > > mailto:avery.p.pa...@gmail.com>> wrote:
> > > >
> > > > On 2/17/2015 11:02 AM, Buck Evan wrote:
> > > >>
> > > >> I think there's only three cases here:
> > > >>
> > > >>  1. Users that would have gotten immediate failure, and no
> > > amount of
> > > >> spinning would help. These users will see their error delayed
> > > by $SVWAIT
> > > >> seconds, but no other difference.
> > > >>  2. Users that would have gotten immediate failure, but could
> > > have gotten
> > > >> a success within $SVWAIT seconds. All of these users will of
> > > course be glad
> > > >> of the change.
> > > >>  3. Users that would not have gotten immediate failure. None of
> > > these
> > > >> users will see the slightest change in behavior.
> > > >>
> > > >> Do you have a particular scenario in mind when you mention
> > > "breaking lots
> > > >> of existing installations elsewhere due to a default behavior
> > > change"? I
> > > >> don't see that there is any case this change would break.
> > > 
> > >
> > > Thanks for the thoughtful reply Avery. My background is also
> > > "maintaining business software", although putting it in those terms
> > > gives me horrific visions of java servlets and soap protocols.
> > >
> > > > I have to look at it from a viewpoint of "what is everything
> > > else in the system expecting when this code is called".  This
> > > means thinking in terms of code-as-API, so that calls elsewhere
> > > don't break.
> > >
> > > As a matter of API, sv-check does sometimes take up to $SVWAIT
> > > seconds to fail.
> > > Any caller to sv-check will be expecting this (strictly limited)
> > > delay, in the exceptional case.
> > > My patch just extends this existing, documented behavior to the
> > > special case of "unable to open supervise/ok".
> > > The API is unchanged, just the amount of time to return the result
> > > is changed.
> > >
> > > > This happens because the use of "sv check (child)" follows the
> > > convention of "check, and either succeed fast or fail fast", ...
> > >
> > > Either you're confused about what sv-check does, or I'm confused
> about
> > > what you're saying.
> > > sv-check generaly doesn't fail fast (except in the special case I'm
> > > trying to make no longer fail fast -- svrun is not started).
> > > Generally it will spin for $SVWAIT seconds before failing.
> > >
> > > > Without that fast-fail, the logged hint never occurs; the
> > > sysadmin now has to figure out which of three possible services in
> > > a dependency chain are causing the hang.
> > >
> > > Even if I put the above issue aside aside, you would

RE: runit maintenance - Re: patch: sv check should wait when svrun is not ready

[James Powell]

You could always craft a rudimentary Makefile, autogen.sh, and configure script 
set in the tree root that can be used. Then again, I like others, just do 
install -v XXX and cp -a to the files to directories as needed anyways, and 
retune to sv scan default directory in patch.

Sent from my Windows Phone

From: Gerrit Pape
Sent: ‎6/‎18/‎2015 7:54 AM
To: supervision@list.skarnet.org
Subject: runit maintenance - Re: patch: sv check should wait when svrun is not 
ready

Hi all,

I'm around, but currently not very active in my open source activities.

runit started in 2001 and was tracked in CVS.  After I took over Debian
maintainership of git in 2005, I converted the repository to git.  The
complete history is available since then

 git clone http://smarden.org/git/runit.git/

Every here and then I think about doing some work on runit, like
integrating patches, but find the file layout in the repo, the build and
installation process, so archaic that I stop again, most of the time.
It's about 13 years old..

Those two things are the two top items on my TODO list.

Regards, Gerrit.


On Thu, Jun 18, 2015 at 10:35:45AM +, James Byrne wrote:
> Similarly, I have two patches which I submitted to the mailing list in 
> February which I would like to get merged:
>
> http://www.mail-archive.com/supervision@list.skarnet.org/msg00500.html
>
> http://www.mail-archive.com/supervision@list.skarnet.org/msg00501.html
>
> It would be useful if Gerrit could respond to confirm whether he is still 
> accepting patches to runit or planning to do any future releases.
>
> Regards,
>
> James
>
> -Original Message-
> From: supervision@list.skarnet.org [mailto:supervision@list.skarnet.org] On 
> Behalf Of Avery Payne
> Sent: 16 June 2015 18:43
> To: Buck Evan
> Cc: supervision@list.skarnet.org
> Subject: Re: patch: sv check should wait when svrun is not ready
>
> I'm not the maintainer of any C code, anywhere.  While I do host a mirror or 
> two on bitbucket, I only do humble scripts, sorry.  Gerrit is around, he's 
> just a bit elusive.
>
> On 6/16/2015 9:37 AM, Buck Evan wrote:
> > I'd still like to get this merged.
> >
> > Avery: are you the current maintainer?
> > I haven't seen Gerrit Pape on the list.
> >
> > On Tue, Feb 17, 2015 at 4:49 PM, Buck Evan  > > wrote:
> >
> > On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne
> > mailto:avery.p.pa...@gmail.com>> wrote:
> > >
> > > On 2/17/2015 11:02 AM, Buck Evan wrote:
> > >>
> > >> I think there's only three cases here:
> > >>
> > >>  1. Users that would have gotten immediate failure, and no
> > amount of
> > >> spinning would help. These users will see their error delayed
> > by $SVWAIT
> > >> seconds, but no other difference.
> > >>  2. Users that would have gotten immediate failure, but could
> > have gotten
> > >> a success within $SVWAIT seconds. All of these users will of
> > course be glad
> > >> of the change.
> > >>  3. Users that would not have gotten immediate failure. None of
> > these
> > >> users will see the slightest change in behavior.
> > >>
> > >> Do you have a particular scenario in mind when you mention
> > "breaking lots
> > >> of existing installations elsewhere due to a default behavior
> > change"? I
> > >> don't see that there is any case this change would break.
> > 
> >
> > Thanks for the thoughtful reply Avery. My background is also
> > "maintaining business software", although putting it in those terms
> > gives me horrific visions of java servlets and soap protocols.
> >
> > > I have to look at it from a viewpoint of "what is everything
> > else in the system expecting when this code is called".  This
> > means thinking in terms of code-as-API, so that calls elsewhere
> > don't break.
> >
> > As a matter of API, sv-check does sometimes take up to $SVWAIT
> > seconds to fail.
> > Any caller to sv-check will be expecting this (strictly limited)
> > delay, in the exceptional case.
> > My patch just extends this existing, documented behavior to the
> > special case of "unable to open supervise/ok".
> > The API is unchanged, just the amount of time to return the result
> > is changed.
> >
> > > This happens because the use of "sv check (child)" follows the
> > convention of "check, and either succeed fast or fail fast", ...
> >
> > Either you're confused about what sv-check does, or I'm confused about
> > what you're saying.
> > sv-check generaly doesn't fail fast (except in the special case I'm
> > trying to make no longer fail fast -- svrun is not started).
> > Generally it will spin for $SVWAIT seconds before failing.
> >
> > > Without that fast-fail, the logged hint never occurs; the
> > sysadmin now has to figure out which of thre