Bugzilla – Bug 121925
External YaST installation source don't refresh
Last modified: 2005-11-16 09:54:24 UTC
A while ago I created my own installation source for OpenSUSE/SuSE 10.0. Feel free to use it for testing: PROTOCOL: HTTP SERVER: 81.169.140.126 DIRECTORY: rpm/wesnoth/10.0 I figured out that the installation source does not refresh it's contents if they've changed, even if I marked "Always Refresh" in the Yast "change installation source module". In the first run, I have made a mistake because I did forget to update the media file in media.1, which would trigger YaST to refresh the source. But now, I took care for the media file, recreated the whole directories, and still have the old content. Only if I completely remove the installation source, and add it again, contents will be updated.
Fixed in yast2-packagemanager-2.13.5. Your description perfectly fits the bug fixed in the above version. In case it does not work for you, reopen the bug. We'll do further investigations then.
Many thanks Michael! This fixes it for me! Now all we need would be a fix for the outer world :)
I have the same problem even with local repository and i reported it as #128379 I hope this fix will hit the mirrors soon :-)
Bug #128379 is a different kind of problem.
SWAMP-ID is #2621
Fixed in yast2-packagemanager-2.12.21 for update SL10.0.
Yesterday, 17th october 2005, I wanted to update my packman packages from Göttingen server (ftp3.gwdg.de). As this server was very slow, I changed it in installation source for ftp4.gwdg.de (keeping same path : pub/linux/misc/packman/suse/10.0) I opened yast update software and saw no update on ftp4.gwdg.de, concerning packman link even with refresh option activated. Then, I deleted this link and added again to the installation source. Back in software upgrade, I could get kaffeine-0.7.1-3 and libxine1-1.1.0-12 Other friend of me have noticed this problem. Only security updates works well. In my particular case, I switched from one ftp server to another one. I noticed that Göttingen servers are not synced each other (today, 18th october, I can't find kaffeine-0.7.1-3 on ftp3.gwdg.de, but only on ftp4.gwdg.de)
This might be exactly, what yast2-packagemanager-2.12.21 fixes. YaST tells that the source data were refreshed, but continues to offer the old content. See Comment #7: I submitted a fix yesterday, 17th october 2005. It will soon be available on our update server. You should not experience this problem anymore, after you updated to yast2-packagemanager-2.12.21.
released
Sorry Michael, yast2-packagemanager-2.12.21 does not fixe this refresh problem. I updated it today, 20th october. I searched for a newly updated package and saw balance-3.28-1 dated 10/20/05 in suser-guru repository. Automatic refresh was already activated and showed to me a normal refresh message for suser-guru source. I forced also a manual updating of the source, but I can only see again balance-3.26 Then, I checked the 2 files packageinfo.xml and package.en in setup/descr directory. These files are up to date and indicate balance-3.28 name package.
I will recheck this, but since I've tested the new yast2-packagemanager I've altered my installation source 2 times, and in both cases it succeded.
Let's see. I have two test machines. The one that always succeds when refreshing the source (two times succesful) did not had the installation source setup when I installed yast2-packagemanager. But since it is installed, it refreshes the source correct. (and yes, I did changed my source meanwhile) Now I've tested it on a system that already had the installation source setup before installing the update, and it does not succeed in refreshing.
[Holger] Silly question: Did you restart YaST after the update (otherwise you refreshed still using the old lib)? What you describe can't be, because there's nothing in the installation source cache, which could tell whether it was created before or after the update to 2.12.21. Sorry but I don't experience this kind of problem. I'm using STABLE via ftp, and it changes frequently. And refresh works. I'd need the y2log files (content of /var/log/YaST). [Gilles] I'll check the manual refresh, it should do a forced reload of the metadata. So after a manual refresh the data should be available anyway. The automatic refresh seems to be a problem of ftp.gwdg.de. Indication for the necessity to reload the metadata is a changed timestamp in the media.1/media file. Looks like ftp.gwdg.de updates the packages and package metadata, but not the timestamp after everything is done. I'll contact the admin to fix this.
Created attachment 55111 [details] Yast2 logs after 3 manual updates
Michael, you're right. Let's have a look at ftp://ftp4.gwdg.de/pub/linux/misc/packman/suse/10.0/media.1 directory last media file update is dated 08/15/05 and media file's timestamp is : Packman 20050815170556 1 supplementary KDE source has the same problem since media file's timestamp is : SuSE Linux AG 20030212001441 1 I performed 3 manual updates on suppl. KDE, packman, suser-guru at 10/210/05 20:06 and added y2log as a new attachment.
Today, 10/24/05, Göttingen ftp4 server has been updated. media file timestamp is now correct for packman at ftp://ftp4.gwdg.de/pub/linux/misc/packman/suse/10.0/media.1 last media file update is dated 10/23/05 and media file's timestamp is : Packman 20051023193006 1 Again, I miss k3b 0.12.5 and I can't see libmusepack after an automatic refresh. I performed also a manual update : same problem. I have added new attachment which y2log traces.
Created attachment 55179 [details] Yast2 logs dated 10/24/05 after automatic refresh and 3 manual updates
Most probabely you see 'k3b-0.12.4_0.1-1.guru.suse100.kde34'. According to the log SUSE LINUX-10.0- from dvd:/// SUSE LINUX-10.0- from ftp://ftp.belnet.be/li... guru-10.0- from ftp://ftp4.gwdg.de/pu... are the only active sources. Packman-10.0-0 from ftp://ftp4.gwdg.. supplementary KDE 3.4.x-3.4- from ftp://ftp4.gwdg are disabled, thus do not contribute packages. If you enable them you should see their packages. And note: YaST favors architecture over version. Per default it will offer a package of the same architecture as the already installed package, or of the best available architecture if it's not instlled. Even if packages of different architecture are available in a higher version. You can check the 'Versions' tab to see whether the package is realy missing or if YaST has chosen an other package as default candidate.
Michaël, It seems I messed my test this morning. I believed all sources were enabled. According your answer, I activated suser-guru and packman and this afternoon I can get k3b 0.12.5 with libmusepack. On Göttingen servers, KDE supplementary repository is not yet up to date. His file is dated 11/17/03. thanks for your help.
*** Bug 133583 has been marked as a duplicate of this bug. ***
For Michaël Gross : Bug 133558 is not exacly a duplicate of this bug, since this problem has 2 parts : - the software part has been resolved with yast2-packagemanager-2.12.21 in this bug report - Michael Andres has contacted Göttingen admin and a corrective action has been effective for media.1/media timestamp file part of this problem. But only for packman and suser-guru repositories until now. Suse team is responsible for suppl. KDE/GNOME repositories. As suppl. KDE/GNOME repositories are also very important and often updated, can you take into account those into your administrative scripts ?
Adrian told me that he updated his scripts. So the KDE/GNOME repositories will soon be operational too.