possible bugs in "system-config-kickstart"

Chris Lumens clumens at redhat.com
Thu Nov 9 15:33:30 UTC 2006


> #1 - at startup I get the following messages. Are they the reason I can't past into
> the %pre and %post sections?
> 
> system-config-kickstart 
> 
> (system-config-kickstart:29362): Gdk-WARNING **: Connection to display
> localhost:11.0 appears to be untrusted. Pointer and keyboard grabs and inter-client
> communication may not work as expected.
> Cannot open logfile /tmp/tmpjPpdY5/var/log/yum.log

Yes, probably.  Are you connecting from a remote system and using ssh -Y?
If you are running as root, you no longer need to if you have the latest
system-config-kickstart installed.  I received a patch that fixes this.

> #2 system-config-kickstart automatically goes to gather package information even
> though I just want to change a few lines in an already existing ks.cfg file for
> which the package information has ALREADY been gathered. I think it should do this
> only if creating a new file.

What if you wanted to modify the package selections?  If you create your
file and then modify it relatively soon after, this information should
all be cached and you won't see such a long startup time.  This is
configurable within yum.

> #3 If I create a new ks.cfg file and save it and then go back and load it again to
> add %pre/%post commands, the resulting ks.cfg file is quite different than the
> original file.

Are there substantive differences, or have things just been reordered?
I'm not concerned about ordering differences (except for script order
changes), but real differences are a problem.

> #4 When configuring a static ip address the tool will you enter more than 3
> characters for each octet. I would expect the tab key (which works) OR a "." OR
> having entered character #4 to switch to the next octet. Currently the tool does NOT
> do this.

Those UI elements should just go away in favor of a single text entry
box, as that's what anaconda does now.  I am trying to keep
s-c-kickstart at least somewhat close to anaconda though it seems to be
a losing battle.

> #5 During the first "session" with this tool, I receive additional messages as
> follows:
> 
> /usr/lib/python2.4/site-packages/pirut/GroupSelector.py:333: GtkWarning:
> gtk_tree_view_scroll_to_point: assertion `GTK_WIDGET_REALIZED (tree_view)' failed
>   gobject.idle_add(lambda x: x.scroll_to_point(0, 0), tree)
> /usr/share/system-config-kickstart/kickstartGui.py:175: GtkWarning: Coercing
> GDK_INPUT_ONLY toplevel window to GDK_INPUT_OUTPUT to work around bug in Xorg server
>   gtk.main()

Yes, I have seen this though I have not spent any time working on it.
The first is either a pirut bug or how I am using pirut.  The second I'm
not sure about yet.  I'll try to make some time to look into the source
of these.

> #4 - I want to save this file but the "save file" dialog requires me to enter the
> filename I want to save as again. Isn't it logical to put up the original filename
> in the prompt?

Yes, and it does that for me.  I'll have to look at this.

> #5 - running diff on the first file generated and saved vs the second file saved
> where I ADDED 4 characters in total as descripbed in #2 above. The net change
> appears to be the "reboot" addition even though I did NOT specify the reboot option.

Looks like when the file is loaded, the reboot checkbox isn't getting
set correctly so it's always checked.  Then when we go to write out the
file, we check the state of the checkbox and since it's checked, you get
reboot.  Easy fix.

> 44c46
> < testing 1 2 3
> ---
> > testing 1 2 3 3a
> 46c48
> < testing 4 5 6
> ---
> > testing 4 5 6 6a

What's this about?

> 51d52
> < @base
> 53d53
> < @admin-tools
> 54a55,56
> > @admin-tools
> > @base
> 56c58
> < @x-software-development
> ---
> > @java-development
> 65c67,68
> < @java-development
> ---
> > @x-software-development
> > @system-tools
> 73a77
> > @graphics
> 76,78d79
> < @system-tools
> < @server-cfg
> < @graphics
> 82c83
> < @ruby
> ---
> > @server-cfg
> 85a87
> > @ruby
> 87d88
> < @engineering-and-scientific
> 88a90
> > @engineering-and-scientific

Not quite sure, but I wouldn't worry about it unless you notice groups
being added or dropped.

- Chris




More information about the fedora-test-list mailing list