Re: GNU Shepherd 0.10.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

Thank you shepherds!  Also the explanations in the news are great.
Finally I understand why GOOPS is not desirable in shepherd.

For Guix Home:

Ludovic Courtès  writes:
> In your operating system configuration (and similarly for your
> ‘home-environment’), make the following changes:

For Guix Home, it works for me to put this in home-environment; no need
to fiddle with home-environment-essential-services.

(home-environment
  …
  (services
   (list (service home-shepherd-service-type
  (home-shepherd-configuration
   (shepherd shepherd-next)))
 …


Regards,
Florian

Re: GNU Shepherd 0.10.0rc1 available for testing!

[Pjotr Prins]

Awesome work! Note that you can run shepherd in user land too - that
is a great feature.

Pj.

On Fri, Apr 28, 2023 at 03:37:12PM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> I am pleased to announce that the first release candidate of version
> 0.10.0 of the GNU Shepherd is available for testing!
> 
> If you’re using Guix System or Guix Home, check out the instructions
> below to give it a try.  Please report success or failure!  If you had
> problems with previous versions, please check if they’re still there.
> 
>   code: https://alpha.gnu.org/gnu/shepherd/shepherd-0.10.0rc1.tar.gz
>   signature: https://alpha.gnu.org/gnu/shepherd/shepherd-0.10.0rc1.tar.gz.sig
>   sha256: 1x3lxsi6xhhds4pq30c3shydmhiidkf1wl2l7mxkpklmlycnbqgg
> 
> In your operating system configuration (and similarly for your
> ‘home-environment’), make the following changes:
> 
>   (use-modules (gnu packages admin))
> 
>   (define shepherd-next
> (package
>   (inherit shepherd)
>   (version "0.10.0rc1")
>   (source (origin
> (method url-fetch)
> (uri (string-append
>   "https://alpha.gnu.org/gnu/shepherd/shepherd-;
>   version ".tar.gz"))
> (sha256
>  (base32
>   "1x3lxsi6xhhds4pq30c3shydmhiidkf1wl2l7mxkpklmlycnbqgg"))
> 
>   (operating-system
> ;; …
> (essential-services
>  (modify-services (operating-system-default-essential-services
>this-operating-system)
>(shepherd-root-service-type
> config => (shepherd-configuration
>(shepherd shepherd-next))
> 
> You can then reconfigure, reboot, and enjoy!
> 
> You can also help with translation.  An updated PO template should soon
> be available at the Translation Project:
> 
>   https://translationproject.org/domain/shepherd.html
> 
> My goal is for 0.10.x to be the last series before 1.0.  The list of
> changes is quite long—see the ‘NEWS’ excerpt below.
> 
> Feedback more than welcome!
> 
> Ludo’.
> 
> 
> * Changes in 0.10.0 (yet to be released)
> 
> ** Distinguish ‘starting’ and ‘stopping’ intermediate service statuses
> 
> In previous version, a service would be either “running” or “stopped”.  The
> intermediate states “starting” and “stopping” are now properly captured and
> you can see them when running ‘herd status’.
> 
> ** ‘start’ and ‘stop’ block when service is already being started/stopped
>   
> 
> With previous version, a client running ‘herd start SERVICE’ while SERVICE is
> already being started would cause shepherd to attempt to start a second
> instance of that service, ultimately resulting in confusion, disappointment,
> and frustration.
> 
> This is no longer the case: when a service is already being started/stopped,
> additional invocation of ‘herd start’ or ‘herd stop’ now block until the
> service is running/stopped.
> 
> ** ‘shepherd’ starts services in parallel
> 
> Services started with ‘start-in-the-background’ and more generally service
> dependencies get started in parallel.  This can reduce startup times in case
> of a “wide” service dependency graph with some services that take a while to
> start.
> 
> ** ‘shepherd’ keeps track of failures and status change times
> 
> For each service, shepherd maintains an event log including the time of recent
> status changes as well as the time of startup failures, if any.  The ‘herd
> status SERVICE’ command now shows the time when the service entered its
> current status and whether it failed to start; ‘herd status’ also prominently
> lists services that failed to start.
> 
> ** New ‘herd log’ command
> 
> Related to the previous item, the new ‘herd log’ command displays an aggregate
> of the service event logs, showing the time at which each service changed
> statuses.
> 
> ** New ‘herd graph’ command
> 
> The new ‘herd graph’ command emits a Graphviz/Dot representation of the
> service dependency graph, which can be viewed for example with ‘xdot’:
> 
>   herd graph | xdot -
> 
> Guix System users get similar information with ‘guix system shepherd-graph’
> (and likewise for Guix Home).  The difference here is that this reflects the
> current system status, showing transient services, services that failed to
> start, and so on.
> 
> ** ‘herd’ output is colorized
> 
> At long last!  We hope you’ll enjoy a little bit of coloring to highlight
> important bits in the output of various commands.
> 
> ** New services shipped: ‘monitoring’ and ‘repl’
> 
> The Shepherd now ships with optional services—see “Service Collection” in the
> manual.  The ‘monitoring’ service logs resource usage of the ‘shepherd’
> process itself.  The ‘repl’ service runs a read-eval-print loop (REPL) in the
> ‘shepherd’ so you can hack it live—enjoy it, but handle it with care!
> 
> ** Socket-actived, systemd-style services can now be started eagerly
> 
> The ‘make-systemd-constructor’ procedure has a 

New Romanian PO file for 'shepherd' (version 0.10.0rc1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the Romanian team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/ro.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Build dependency inflation (was: Re: Core-updates merge)

[Christopher Baines]

Simon Josefsson via "Development of GNU Guix and the GNU System distribution." 
 writes:

> [[PGP Signed Part:Undecided]]
> Andreas Enge  writes:
>
>> - Too much in Guix depends on too much else, which makes building things
>>   needlessly entangled; in particular time zone data should not be referred
>>   to by packages, but be loaded at runtime (Leo Famulari).
>
> This is an important open problem -- is there any way to attack this
> problem in a systematic way?  I guess it is hard to understand which
> packages ends up depending on what since it is a large graph with long
> cycles, and also to understand which build depencies are essential and
> which are superficial, and thus consequently challenging to know where
> to start working to reduce build dependencies?
>
> I wonder if it is possible to graph all the build dependencies, and do
> something like a monte-carlo what-if simulation: randomly pick one
> build-dependency from the entire build-dependency graph and remove it,
> and recompute the graph.  If the difference between these two graphs
> leads to a significantly lower total build computational cost than
> before, we may be on to something.  My theory is that "true" build
> dependencies will show up in so many places that removing just one
> instance of it will not affect total build time.  But "needless" build
> dependencies may occur just once or few times, and this approach would
> catch low-hanging fruit to work on.  Maybe the simulation needs to be
> done on more than just removing one build-dependency, it could play
> what-if games removing two build-dependencies etc, or three random
> build-dependencies, and so on.  Maybe my idea is flawed, and this will
> only lead to a list of build-dependencies that are impossible to get rid
> off anyway.
>
> Is there some other method to understand what build dependencies would
> be important to remove, to speed up total rebuild time?
>
> Maybe we could analyze how much of a particular build-dependency
> actually is used by a particular build?  By looking into file-access
> patterns etc.

This is something I'd like to see incorporated in to qa.guix.gnu.org for
patch (and branch) review. While one off analysis is good, I think it's
most important to be able to look at changes and see how they change the
situation.


signature.asc
Description: PGP signature