civodul pushed a commit to branch main
in repository shepherd.

commit bee4e4aa16846c912879f5c0b4882abe80fb0949
Author: Ludovic Courtès <l...@gnu.org>
AuthorDate: Sun Mar 16 11:59:10 2025 +0100

    NEWS: Promote entry headings.
---
 NEWS | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/NEWS b/NEWS
index 8c20ed5..b954fa7 100644
--- a/NEWS
+++ b/NEWS
@@ -13,47 +13,47 @@ Please send Shepherd bug reports to bug-g...@gnu.org.
 
 * Changes in 1.0.3
 
-*** ‘spawn-command’ now honors #:log-file
+** ‘spawn-command’ now honors #:log-file
 
 The ‘spawn-command’ procedure now accepts a #:log-file argument, just like
 ‘fork+exec-command’.
 
-*** New ‘--syslog’ option of ‘shepherd’
+** New ‘--syslog’ option of ‘shepherd’
 
 This option forces shepherd to write its output to syslog (the /dev/log socket
 by default).  This is already the case when shepherd runs as root so this
 option only makes sense for non-root shepherd instances, and its primary
 purpose is testing.
 
-*** Always decode client commands as UTF-8
-    (<https://issues.guix.gnu.org/76244>)
+** Always decode client commands as UTF-8
+   (<https://issues.guix.gnu.org/76244>)
 
 Previously client commands send by ‘herd’ would be decoded according to the
 locale encoding of the ‘shepherd’ process, which could be ASCII; now they’re
 always decoded as UTF-8, as intended.
 
-*** Internal logging is always UTF-8
-    (<https://issues.guix.gnu.org/76244>)
+** Internal logging is always UTF-8
+   (<https://issues.guix.gnu.org/76244>)
 
 The so-called “service output port”, where internal logging from shepherd
 itself goes, is now always UTF-8-encoded (instead of following locale
 encoding).
 
-*** Log output missing a newline is preserved
-    (<https://issues.guix.gnu.org/76243>)
+** Log output missing a newline is preserved
+   (<https://issues.guix.gnu.org/76243>)
 
 It used to be that service output missing a final newline would not be logged,
 for example when running “herd spawn transient -- echo -n aaaaa”.  This is now
 fixed.
 
-*** Default generated configuration file updated to match current interface
-    (<https://issues.guix.gnu.org/76403>)
+** Default generated configuration file updated to match current interface
+   (<https://issues.guix.gnu.org/76403>)
 
 The ~/.config/shepherd/init.scm generated when it doesn’t already exist would
 use deprecated and removed interfaces.  This is now fixed.
 
-*** Inhibit service respawn during shutdown
-    (<https://issues.guix.gnu.org/76338>)
+** Inhibit service respawn during shutdown
+   (<https://issues.guix.gnu.org/76338>)
 
 Until now, the ability to respawn services remained functional during shutdown
 (with ‘herd stop root’, ‘reboot’, etc.).  This caused troubles on Guix System
@@ -61,22 +61,22 @@ where the ‘user-processes’ service terminates all processes 
when it is stopp
 and which, as a consequence, could lead shepherd to respawn services, even
 though it was being shut down.
 
-*** Tolerate slight delays when waiting for a timer event
-    (<https://issues.guix.gnu.org/76516>)
+** Tolerate slight delays when waiting for a timer event
+   (<https://issues.guix.gnu.org/76516>)
 
 Previously, timers could occasionally get slightly more than a 2-second delay,
 which would lead them to skip their deadline (with a message saying “resuming
 from sleep state?”).  Delay tolerance has been increased.
 
-*** Silence warning about ‘environ’ when using Guile 3.0.10
-    (<https://issues.guix.gnu.org/76343>)
+** Silence warning about ‘environ’ when using Guile 3.0.10
+   (<https://issues.guix.gnu.org/76343>)
 
 When using Guile 3.0.10, commands such as ‘shepherd --help’ would print an
 erroneous warning about ‘environ’ being called from a multi-threaded context.
 This is now fixed.
 
-*** Correctly report the exit status of processes terminated early
-    (<https://issues.guix.gnu.org/76790>)
+** Correctly report the exit status of processes terminated early
+   (<https://issues.guix.gnu.org/76790>)
 
 For services using ‘fork+exec-command’, there used to be a small window after
 creating the process and before monitoring it during which process termination

Reply via email to