runit (2.1.2-61) unstable; urgency=medium

    invoke-run(8) no longer checks for policy-rc.d; the test has been moved into
    runit trigger (/lib/runit_trigger_sv) as well as into runit-helper.
    As a consequence it is now possible for the local admin to enable and run a
    service even when policy-rc.d would deny such action; on the other hand,
    maintainer script (both runit-helper and triger_sv) will now no longer enable
    a service as long as policy-rc.d returns 101.

    In order to reduce the diff with upstream, the patch to move communication files
    under /run has been dropped; the runit package now ships /etc/runit/stopit and
    /etc/runit/reboot as symlinks with targets in /run. However, the rest of the runit
    integration will continue to look for old location in /run, so symlinks in /etc/runit/
    should not be removed, even if they are dangling.

 -- Lorenzo Puliti <plorenzo@disroot.org>  Wed, 30 Oct 2024 02:54:32 +0100

runit (2.1.2-60) unstable; urgency=medium

    runit-init binary moved:

    runit-init binary is now shipped in /usr/sbin/ , previously was under
    [/usr]/lib/runit/ ; everything in package now refers to the new
    location but locally maintained symlinks, if any, need to be updated.

    /etc/service as symlink:

    Since runit_2.1.2-7 /etc/service is shipped as symlink but before
    2.1.2-5 it was shipped as directory; at the time there was no warning
    to the user and no transition was arranged so old setups with /etc/service
    as directory still exists today.
    As other parts of the package may rely on /etc/service being a symlink, such
    old setups are likely to become buggy in a way that is difficult or impossible
    to fix.
    Users with old installations are encouraged to convert /etc/service to a symlink
    that points to /etc/runit/runsvdir/current; an example of code to perform the
    conversion can be found at
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069267

 -- Lorenzo Puliti <plorenzo@disroot.org>  Thu, 09 May 2024 23:24:51 +0200

runit (2.1.2-58) experimental; urgency=medium

    Change in service layout:

    Until now package and local services coexisted under /etc/sv/,
    with dpkg handling services files as conffiles.
    Since this version packages are allowed to ship their service under
    /usr/share/runit/sv/; when they do so, /etc/sv/ becomes reserved for local
    (supposedly modified) copy of that service.
    When a service exists in both location, the copy in /etc/sv/ will have a higher
    priority and tools such as update-service(8) and trigger_sv have been
    updated to reflect this change.

    update-service(8):

    update-service(8) no longer requires full path of the service to add or
    remove a service to system-wide supervision;  first <service> is
    searched in /etc/sv/<service>, then in /usr/share/runit/sv/<service>.
    The full path is required only if <service> is in a different location.

 -- Lorenzo Puliti <plorenzo@disroot.org>  Fri, 08 Mar 2024 14:34:46 +0200

runit (2.1.2-51) experimental; urgency=medium

    Invoke-run(8) now uses the env subdirectory to set variables for the
    runscript with chpst's envdir; previously the subdirectory was conf.
    This is documented in invoke-run manpage.

    The cpsv(8) program shipped with this version of runit has a non
    backward compatible change in the syntax in order to separate
    option and commands.

 -- Lorenzo Puliti <plorenzo@disroot.org>  Sun, 04 Dec 2022 14:34:46 +0200

runit (2.1.2-50) unstable; urgency=medium

    Deprecation of default/runit and $NAME:

    * /etc/default/runit file is deprecated and will be removed in future,
       equivalent settings can be obtained with 'verbose' and 'debug'
       flag files.
    * invoke-run will soon stop exporting the NAME variable for runscripts,
       please see invoke-run(8) for details.

    Flag Files:

    * Several flag files that affect runit's behaviour can be placed under
       /etc/runit/ directory; their name and effect is documented in the
       /etc/runit/README file.

    init-functions.d/40-runit and start-stop-daemon.runit wrapper:

    * Since runit 2.1.2-49, when both a /etc/sv/foo runscript and a /etc/init.d/foo
      sysv script exists, calls to the foo sysv script are masked and commands
      are forwarded to the foo runscript. This is enabled by default and happens
      not only during the boot sequence but also at runtime, because of the
      40-runit lsb hijack. This behaviour is configurable with flag files.
    * As an alternative to 40-runit, a start-stop-daemon zsh wrapper is available;
      since init-functions are included in sysv scripts before start-stop-daemon
      is called, in order to use the wrapper the 40-runit lsb hijack should be
      disabled (it can be done with a flag file). The wrapper can be manually
      enabled by diverting the real start-stop-daemon and replacing it with a
      symlink to /lib/runit/start-stop-daemon.runit.

 -- Lorenzo Puliti <plorenzo@disroot.org>  Sun, 16 Oct 2022 17:29:28 +0200

runit (2.1.2-41exp1) experimental; urgency=medium

    If you are using the policy-rc.d hack as a way to control systemd or sysv
    services please be aware that runit's runscripts now check for the
    /usr/sbin/policy-rc.d script via invoke-run(5) interpreter.
    If the script returns 101 the service will be set down; this will prevent
    services to start also during the boot process or when controlled via
    sv program. See invoke-run(5) man page for more details.
    
 -- Lorenzo Puliti <plorenzo@disroot.org>  Wed, 31 Mar 2021 15:36:05 +0200

runit (2.1.2-38) unstable; urgency=medium

    New runit-run package
    
     Before runit 2.1.2-37 sysvinit and systemd integration were provided
     as separate package ( runit-sysv and runit-systemd) but this design
     proved to cause several RC bug (see #953875 and #934646):
     all runit integrations are now merged into a new package called
     runit-run that does not depends on any specific init.
     This change only affects users that are using runit as supervision
     suite under another init system.
    
    Runit in container
    
     You can now boot into a custom rundirectory by passing the
     runitdir=yourcustomdir variable to the kernel command line.
     The directory must exists under /etc/runit/runsvdir/ .
     As a special case (mainly intended for containers), runit package
     provides a 'solo' rundirectory: when this directory is selected, runit will
     also skip all sysv instance of services: be aware that, if used as is, it will
     start only a getty on tty1. This is documented in runit(8) manpage.
     
 -- Lorenzo Puliti <plorenzo@disroot.org>  Wed, 21 Oct 2020 18:32:31 +0200
