After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 114044 - breaks redhat9 network settings.
breaks redhat9 network settings.
Status: RESOLVED FIXED
Product: gnome-system-tools
Classification: Deprecated
Component: network-admin
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Carlos Garnacho
Carlos Garnacho
Depends on:
Blocks:
 
 
Reported: 2003-05-30 14:57 UTC by Murray Cumming
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Murray Cumming 2003-05-30 14:57:51 UTC
After opening g-s-t's network-admin (but without applying anything), I get
this error when trying to open the regular RH9 network tool (neat). This is
with the latest 0.26.1 tarball:

Component: redhat-config-network
Version: 1.2.3
Summary: TB
/var/tmp/redhat-config-network-1.2.3-root/usr/share/redhat-config-network/netconfpkg/NCDeviceFactory.py:43:getDeviceClass:KeyError:
Loopback
Traceback (most recent call last):
  • File "/usr/sbin/redhat-config-network-gui", line 186 in ?
    window = mainDialog()   File "/var/tmp/redhat-config-network-1.2.3-root/usr/share/redhat-config-network/netconfpkg/gui/maindialog.py", line 168, in __init__   File "/var/tmp/redhat-config-network-1.2.3-root/usr/share/redhat-config-network/netconfpkg/gui/maindialog.py", line 239, in load   File "/var/tmp/redhat-config-network-1.2.3-root/usr/share/redhat-config-network/netconfpkg/gui/maindialog.py", line 246, in loadDevices   File "/var/tmp/redhat-config-network-1.2.3-root/usr/share/redhat-config-network/netconfpkg/NCDeviceList.py", line 218, in getDeviceList   File "/var/tmp/redhat-config-network-1.2.3-root/usr/share/redhat-config-network/netconfpkg/NCDeviceList.py", line 109, in load   File "/var/tmp/redhat-config-network-1.2.3-root/usr/share/redhat-config-network/netconfpkg/NCDeviceFactory.py", line 43, in getDeviceClass
KeyError: Loopback
I've tried and repaired this twice, so I'm pretty sure.

Note that I get this error every time I close any g-s-t tool:
** ERROR **: file vte.c: line 6850 (vte_terminal_process_incoming):
assertion failed: (_vte_buffer_length(terminal->pvt->incoming) > 0)
Comment 1 Carlos Garnacho 2003-06-25 08:58:18 UTC
hi!

finally yesterday night I could hunt the bug (sorry for not doing it
before, I still had some exams left after Gu4dec), the patch was
almost one liner, this evening as soon as I arrive home I'll commit
the bugfix to the CVS :-)

just a side note, why the hell does redhat9 store the loopback
configuration in a different directory to the rest of the interfaces??
:-/
Comment 2 Murray Cumming 2003-06-25 09:04:54 UTC
Great. Could you post the ChangeLog entry here when you close this 
bug. I would be interested to know what the problem was.

These config files are very mysterious. We really need to document 
how the various distros work. But you will hear more about that in 
the 2.4 announcement...

Well done.
Comment 3 Carlos Garnacho 2003-06-25 19:21:31 UTC
I've just commited this :-P

the full Changelog entry is:

2003-06-25  Carlos Garnacho Parro  <garnacho@tuxerver.net>
 
        * network-conf.in, network.pl.in, platform.pl.in, 
        runlevel-conf.in,service.pl.in, time-conf.in, users-conf.in:
        s/redhat\-9\.0/redhat\-9/, because it's in this way in 
        /etc/redhat-release, there won't appear the distro selection
        window anymore in redhat9 :-P
        * network.pl.in: (gst_network_ensure_loopback_interface): 
        removed loobpack in redhat9, it isn't really neccesary (I'm
        even thinking about removing loopback support at all in GST)
        and broke the redhat network tool. Fixes #114044
        (gst_network_rh72_get_file): made it to create the interface 
        filename with the "dev" tag instead of the "name" tag 
        (for RH >=7.2)


So I think that the redhat9 support is now fully enabled :-P

regarding to the vte error, I plan to use forkpty stuff again and run
only the backend as root, so we'll get rid of this error :-P (that on
the other hand, I've never experienced :-/)