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

2015-06-22 Thread Avery Payne



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

Gerrit Pape p...@smarden.org 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

2015-06-22 Thread 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

2015-06-20 Thread Lasse Kliemann
Gerrit Pape p...@smarden.org 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

2015-06-19 Thread 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

2015-06-18 Thread 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 Papemailto:p...@smarden.org
Sent: ‎6/‎18/‎2015 7:54 AM
To: supervision@list.skarnet.orgmailto: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 b...@yelp.com
  mailto:b...@yelp.com wrote:
 
  On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne
  avery.p.pa...@gmail.com 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.
  snip
 
  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 wouldn't get a hang,
  you'd get

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

2015-06-18 Thread 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 p...@smarden.org 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 b...@yelp.com
   mailto:b...@yelp.com wrote:
  
   On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne
   avery.p.pa...@gmail.com 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.
   snip
  
   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 wouldn't get a hang,
   you'd get the failure message you're familiar with, just several
   seconds (default: 7) later. The sysadmin wouldn't search any more
 than
   previously. He would however find that the system fails less often,
   since it has that