Bugzilla – Bug 233523
Wrong handling of deacitvated install sources and the switch for zenworks synchronising
Last modified: 2007-01-19 09:18:37 UTC
One can have different installation sources. Using yast2 inst_source to enter the different sources works fine. Problem 1: Using any Yast2 component dealing with this information (sw_single, ...) or zypper leads to loooong time outs when some of the sources are not reachable (even when the source is not enabled!). Since mobile users often have to handle with different sources in different locations (so different nets) this is a very difficult behaviour and makes the whole thing unusable here. I mean really unusable because inst_source does not give the chance to deactivate a source afterwards because it will be completely hidden if not reachable. Of course, since the deactivation will be ignored anyway.... Yast2 components: after the long timeouts one will be able to handle the remaining sources. zypper: if one source is not reachable, it fails completely after the timeout - even for the reachable sources! Problem 2: Trying to disable the zenworks synchronisation in inst_source works only once. Calling inst_source again shows the button switched on again (even if the zenworks stuff is not running or even installed) - oversight of it leads again to long timeouts and errors. The disabling of that synchronisation should really be persistant.
Please attach y2logs. If you are in doubt please follow: http://en.opensuse.org/Bugs/YaST. Thanks!
Hi, sorry, but since this is a company system and I have no idea which confidential information YaST is holding within the logs, I am not able to send them. Beside this: since the zmd stuff is unusable in a mobile environment I have deleted any related rpm (and use smart instead). Sorry.
Problem 1: a duplicate of #223600, yast asks to remove the broken sources at the starts - by this way it's possible to remove the hidden sources. Problem 2: a duplicate of #230727 (Please, enter a separate bug report for each problem next time, multiple problems cannot be tracked properly.) *** This bug has been marked as a duplicate of bug 223600 ***