|
Bugzilla – Full Text Bug Listing |
| Summary: | yast updates repos when trying to set time | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Larry Ewing <lewing> |
| Component: | YaST2 | Assignee: | Katarina Machalkova <kmachalkova> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bryeny, casualprogrammer, forgotten_eDPGYP6_cn, jdsn, jens.nixdorf, thiago.sayao, zscherni |
| Version: | Alpha 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | part of a y2log | ||
|
Description
Larry Ewing
2007-09-21 21:07:17 UTC
I can replicate this on b3. Do you have a screenshot? Can't? Try actually changing the time. Screenshot on the way. Ok, I see it now. Happens in both the gtk and qt version. *** This bug has been marked as a duplicate of bug 326490 *** I have the fix for bug 326490 in my kernel package: * Thu Sep 20 2007 - bwalle@suse.de - Update config files. Revert RTC transition for 10.3 due to problems that cannot be fixed quickly (#326490). This problem is not solved. Please attach YaST logfiles. I don't understand how the repository update actually prevents setting the time - it doesn't finish or what do you mean? > The dialogs prevent setting the system time even though
> they have absolutely nothing to do with it.
>
I also don't have a clue how these progress dialogs can prevent setting system time ;-)
But they are there for a reason - we need to check whether xntp package is installable so that user is not allowed to choose 'synchronize with NTP server' method of setting the time if (s)he cannot install xntp package (with ntpdate) later on.
So, this is partially my fault that in ntp-client_proposal, I check for availability of xntp unconditionally (even if it is already installed), therefore these annoying popups appear each time user wants to change the time.
You can test yast2-ntp-client 2.16.0 as soon as it comes up in Factory tree and see if it is any better
Please try with yast2-ntp-client 2.16.0 I see that this discussion seems to be on Beta version of 10.3. However, I have final version of 10.3 and I am experiencing the same behavior. Specifically as follows in Gnome: 1. Start Yast 2. Select Date & Time 3. Select Change (to change the time) 4. In the next window, (where you can manually change the time or set an NTP server), you immediately start seeing the "Reading installed packages" scanning window and "reading repository cache" scanning window pop up. You have to wait for this to complete before you can do anything. The behavior is the same as when you go to Yast > Software Management, although in this place, the behavior is appropriate. I'm fairly certain setting time has nothing to do with RPM's. :-) Katarina, I'm bit confused, but was this behavior fixed in your proposed 2.16.0 version? It was Package::Available binding responsible for initializing repositories stuff at the beginning of adjusting date & time dialog. It was called unconditionally at all times. Now it is called if and only if xntp package (needed for successful synchronization with ntp server - otherwise this item is disabled) is not yet installed. The issue should be fixed in yast2-ntp-client 2.16.0, but I did not test myself it as I don't use Gnome So it seems to me that this is fixed... Apparently, with 10.3 Final Release, yast2-ntp-client version is 2.15.12-7. I've searched all the repositories that I am aware of and haven't come across the 2.16.0 version. Where can I find this version to install and test? Thanks, Bryen You are right, 2.16.0 is not part of 10.3. You can download it from FACTORY repository: http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/noarch/ Thanks for the link. I downloaded and rpm -qa yast2-ntp-client now says 2.16.0-6. Behavior is now moved further down the line. Previous to this update, the RPM repository scanning occurred as soon as you clicked "change" from the main Clock and Time Zone screen. After this update, the RPM repsoitory scanning occurs ONLY if you select "Synchronize with NTP Server" and click Acecpt. If you simply manually change the clock time/date, or hit cancel, then the RPM scanning won't happen. *** Bug 334132 has been marked as a duplicate of this bug. *** *** Bug 334815 has been marked as a duplicate of this bug. *** Please try with yast2-ntp-client 2.16.1 from Factory. However, if you don't have xntp package installed, you'll still see repository scanning progress. But it is a feature rather than a bug, because it makes no sense to enable synchronization with NTP server if xntp (thus, ntpdate utility) is not installable. If xntp package is installed, you should see no progress at all. These days (and next year when the world changes back to summer time) we'll see more duplicates. But usually changing time isn't a daily operation, so I would see this as annoying not as worth an update. But #19 makes me wonder: shouldn't the option unconditionally be there in the running system and only if you select it, it will check to install xntp? They popups are annoying and slow with many repos and it looks a bit like overkill to have them. Ok, repository scanning (Package::Available) completely removed, as xntp package is available on every media we ship (even on 1CD KDE/GNOME) yast2-ntp-client 2.16.2 *** Bug 339450 has been marked as a duplicate of this bug. *** *** Bug 346709 has been marked as a duplicate of this bug. *** Created attachment 197732 [details]
part of a y2log
This log covers the start of yast in a console, the start of the date/time-module, unwanted repo-refreshing, closing yast and starting again to check it with the same procedure.
Reopened this bug, because it happens still at openSUSE 10.3 final. In my case i wanted to change the timesettings via YaST2 (konsole). At the moment when i select the field "Ändern" (maybe "Change" in english Versions) in the Date/Time-Module in YaST, it starts immediately to refresh all repositories, which lasts around 15 minutes here. xntp is already installed at this machine. See my y2log above. Comment #15 clearly states that fixed package is *not* part of openSUSE 10.3 final, it has been released for Factory (future openSUSE 11.0) only, as the fix was not approved as online update patch for 10.3 by project management (see comment #21) OK, then i will report a new bug, which is not only a dupe. *** Bug 369335 has been marked as a duplicate of this bug. *** (Maybe not "one bug - one request", but somehow belongs together (?))
> annoying sequence of repository update dialogs from yast …
Well, I think it would be good, if all components of yast [1] would ask before this repo-update, if user wants to do it or wants to use the last known state, cause it's really ennoying, waiting for this long-during repository-update in worst case several times a day.
A second problem is, that the opensuse-online-updater looks like the usual yast-installer but sorts the rpms by default in the group "patches" which is only clear. But I miss the filter "patches" in the usual yast-installer! Please include/provide there too.
[1] as /sbin/yast2 online_update, yast2 - software - installation, …
Please do not reopen this bug any more, it is pointless, the original issue (do not scan repositories if it is really not needed) has been fixed long time ago in openSUSE 11.0 > Well, I think it would be good, if all components of yast [1] would ask before > this repo-update, if user wants to do it or wants to use the last known state, > cause it's really ennoying, waiting for this long-during repository-update in > worst case several times a day. Please file a new bug (enhancement) for such request > A second problem is, that the opensuse-online-updater looks like the usual > yast-installer but sorts the rpms by default in the group "patches" which is > only clear. But I miss the filter "patches" in the usual yast-installer! Please > include/provide there too. Again, please file a new bug (enhancement) for that issue, it has nothing to do with ntp-client or timezone dialog (which this bug is about) |