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 <[email protected]> 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 <[email protected]> >> 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@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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
