[systemd-devel] systemd-analyze-197 broken

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 15, 2013 at 01:16:24AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 14, 2013 at 03:55:42PM -0800, Kok, Auke-jan H wrote:
> > On Mon, Jan 14, 2013 at 3:38 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
> > > Am 15.01.2013 00:00, schrieb Jan Engelhardt:
> > >> On Monday 2013-01-14 23:44, Reindl Harald wrote:
> > >>
> > >>> what does systemd-analyze try to tell me?
> > >>> systemd-197 itself works fine
> > >>>
> > >>> [root at testserver:~]$ systemd-analyze
> > >>> Traceback (most recent call last):
> > >>>  File "/usr/bin/systemd-analyze", line 23, in <module>
> > >>>    from gi.repository import Gio
> > >>> ImportError: No module named gi.repository
> > >>
> > >> python is telling you about a missing (python) module named
> > >> gi.repository
> > >
> > > but
> > >
> > > * where does it comre from (gi.repository doe snot tell me anything)
> > 
> > this is up to your distribution to provide, unfortunately.
> > 
> > > * when was it introduced
> > > * why does the package it not pull as dependencie with hopefully
> > >   not again circle-deps to a lot of other packages
> > >
> > > does systemd really need to introduce one 3rd party component
> > > after the next (libmicrohttpd as example) which will sooner
> > > or later terrible break due incompatible changes in this minefiled
> > 
> > I don't think it's as bad as you portray it, but I have an intern
> > software engineer that I will be making systemd-analyze (the non-plot
> > parts - the plot parts should be replaced by bootchart IMO) rewrite in
> > C, so hopefully we can put some of this behind us soon enough.
> I think that fixing a trivial packaging error (one line of missing
> Depends:) with a rewrite from scratch is the wrong way to go.
> The available man-hours would be much better spent improving
> systemd-analyze to provide better diagnostics, nicer output, more
> features, etc. Rewriting it in C serves little purpose: neither it is
> a performance critical program, nor does it run in initrd. Nor
> is it going to be easier to develop. To the contrary, as long as it is
> written in Python, it is trivial to dynamically load the graphical
> libraries only when necessary.  With C code this is possible too, but
> requires _much_ more code.
Regarding features: for example systemd-analyze only shows sucessfully
started programs.  It doesn't say anything useful about .device units
which timed out. It would be incredibly useful to tell the user that
her systemd took 300s to boot up because everything was waiting for a
missing swap partition.

Zbyszek

> > If there are folks interested in this, let me know, so I can
> > coordinate the efforts.