[systemd-devel] systemd-analyze-197 broken

[Holger Winkelmann]

Hi,

I'm just following this discussion and would ask the developer to keep the embedded folks in mind. Embedded systems hardly have all the dependencies available or even phyton but need a debug tool too. So far I know systemd will address this embedded UseCases as well.

Holger 

-- 

Holger Winkelmann
Travelping GmbH
+49-171-5594745

### Sent from a mobile device. Sorry for brevity and typos... ###

On 15.01.2013, at 01:17, Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> 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.
> 
>> If there are folks interested in this, let me know, so I can
>> coordinate the efforts.
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel