Created attachment 155657 [details]
Rebuild it

Created attachment 155658 [details]
After rebuilding the error still exists in Yast software management

Because of this error, little or nothing can be done in terms of adding, deleting or otherwise maintaining software.   If you had installed a minimum system, you won't be able to add video or audio players or media editors.  Even system updates and patches will likely fail.

I spent about 18 hours trying to get around this bug.   I had to reinstall all the way back to Alpha 5 to find a version that did not have this bug.   I eventually was able to install A6 and replace the YAST2 and ZYPPER and LIBZYP modules from the A5 DVD to make A6 work properly.   I then attempted an upgrade to A7.   I never was able to get A7 to do an upgrade install due to dependencies failures.  Eventually, the dependencies box would be displayed blank as if there was still a unresolved dependency, but nothing showed.   Pressing cancel attempting to continue the installation resulted in bringing me back to that blank dialog box.   Therefore, I am unable to update to A7.   It appears there is a version conflict in one of the YAST2 or ZYPPER libraries between A5 and A6-7.

Please try to reproduce the bug, if possible, and attach yast2 logs (here's how to do it: http://en.opensuse.org/Bugs/YaST )

libzypp had a bug before where it was not able to upgrade itself the database when it internal structure change. IIRC this bug s fixed since alpha7.

Still, you may have accepted a disclaimer that inter-alpha upgrades are not supported at all.

Have you tried to reproduce this bug in a clean installation?

Please try to reproduce it when upgrading from alpha7 to the next beta. And attach the logs. Thanks!

I did try several times, including a clean installation rather than an
upgrade with similar results.   Finally I reverted to A5 and started
re upgrading through the A6 and A7.   A6 Exhibited the same type of
failure but as I didn't change anything previously, I hadn't noticed.  
With A7, the addition of Factory and the automatic destruction of my
previous repository pointers forcing re-entry, the bug hit full force.  
So, I restarted with A5 and again upgraded to A6 but replaced the
libzypp from the A5 dvd which allowed it to function.  When I tried to
upgrade using A7, I couldn't get past the dependency checks, so I left
it at A6 with the A5 library.  

I am wiping my drive and attempting a clean install of A7 so I can
generate the requested logs as the originals were wiped long ago.   *Is
there an updated libzypp I can download to plug into the A7 so I can
make it work?*

I am intimately aware that Alpha software comes with no warrantee or support however I actively am attempting to help you locate and repair bugs in your product.   

As you are aware that this problem is caused by the LIBZYPP library, I will not forward the log files unless requested again but I will generate them so they will be available on a USB stick.

Thanks

Duncan, please take care of this (or reassign to appropriate zypp folks)

The bug I am thinking of was fixed here in the changelog:

-------------------------------------------------------------------
Fri Aug  3 14:13:36 CEST 2007 - dmacvicar@suse.de

- Fixed cache schema upgrade

Ok, I did a clean install of A7.  I did NOT allow the default repositories to modify the installation software library or register until the installation was complete.   I then made a dump of the yast2 logs (if you want them).   Next, I added the FACTORY repository entries and immediately updated zypper and its libraries from the FACTORY.  Next, I selected all of YAST2 and selected update if newer available for the entire list which went OK.  I then added 3 external repositories from the OpenSuse.org website (Packman, Guru and VLC) which all worked on Alpha 5 and immediately an error occurred, (2 attachments).  I dumped the Yast2 logs (1 attachment if you need it).   This seems related but different in that the database doesn't seem corrupted, but remains unusable until the external repositories are disabled. Thus, only the FACTORY repository can be used. 

Created attachment 155970 [details]
Showing error with external repository turned on

Created attachment 155971 [details]
Initialization error with external repository enabled

Note also that the error dialog does NOT tell you WHICH repository(s) had the problem.   THe first time, I had 3 external repositories turned on and I turned off combinations until I figured out that *any* external other than FACTORY would caus this error.   I assume that the dialog box is supposed to tell you WHICH repository is causing the problem?   Once the error occurs, no further processing of external repositories seems to occurs and your database is locked and you cannot search or make changes to your system until you turn off the offending external repo and then restart the program.   At least now, it isn't corrupted the way it used to be so progress is being made on this problem.

I sacrificed another machine (I have 4) in the interest of finding the problem.  The machine was a functioning 10.2 machine.   I attached to the FACTORY repo and replaced ONLY the ZYPPER package (and the libraries it autoselected).   It promptly destroyed the existing repo selections but allowed me to re-add the FACTORY and all 3 of the repos that A7 cannot communicate with, namely the Pacman, Guru and VLC repos listed on the OpenSuSE.org website with NO problem whatsoever.    It also allowed me to update the VLC, Mplayer, Xine and XMMS packages from those sites and resolve all dependencies. As I did NOT replace any of the YAST2 modules from FACTORY, I am of the conclusion that the 10.2 modules are compatible with the zypper package (which was malfunctioning on 10.2 anyhow) and the problem remaining in A7 is NOT in the zypper module but is in the module that goes to the third party repo and gets the repo data to add to the local database.  In 10.2, the module works with whatever data is available in all three of those sites, but A7 it doesn't work at any of them.   I tried A7 in FTP and HTTP modes with identical results so it is content, not protocal.   The machine I sacrificed is now a hybrid and is quite happy.

I need logs.

It may not be YaST causing it, as zypper from the command line does this as well.

Try 

zypper ar http://download.videolan.org/pub/videolan/vlc/SuSE/10.3 Videolan-openSUSE-10.3

then 

zypper ref

in my case it reports:

zypper ref
Refreshing 'openSUSE-10.3-Beta1-iso'
* Building repository 'openSUSE-10.3-Beta1-iso' cache
Refreshing 'Videolan-openSUSE-10.3'
Not found: Media Exception
Error reading repository 'Videolan-openSUSE-10.3':
Valid metadata not found at specified URL(s)
Skipping repository 'Videolan-openSUSE-10.3' because of the above error.
Refreshing 'openSUSE-10.3-KDE-iso'
* Building repository 'openSUSE-10.3-KDE-iso' cache
Refreshing 'openSUSE-10.3-Factory'
* Building repository 'openSUSE-10.3-Factory' cache
Refreshing 'openSUSE-10.3-Updates'
* Building repository 'openSUSE-10.3-Updates' cache
Refreshing 'openSUSE-10.3-Debug'
* Building repository 'openSUSE-10.3-Debug' cache
Refreshing 'openSUSE-10.3-Extra'
* Building repository 'openSUSE-10.3-Extra' cache
Some of the repositories have not been refreshed because of error.

This did work in alpha 6

cat /etc/SuSE-release
openSUSE 10.3 (i586) Beta1
VERSION = 10.3

uname -r
2.6.22.1-16-default

rpm -qa | grep zypp
libzypp-3.13.13-2
zypper-0.8.9-2

Created attachment 156900 [details]
YaST2 Logfiles

Created attachment 156901 [details]
ZYPPER Logs

Re: comment #11, 

this may be a bug in its own right. yast2 sw_single always stops reading repositories after the first error encountered and does not give an indication just which repo failed. zypper leafs through _all_ of them and lists the results per repository

(In reply to comment #13 from Duncan Mac-Vicar Prett)
> I need logs.
> 

Sorry I took so long to reply.  I had to take the machine down and restore it to 10.2 because I am also working on a raid5 problem.   This problem is almost assuredly caused by https://bugzilla.novell.com/show_bug.cgi?id=297627#c5 so if you will follow that thread, I think you will also solve this bug.  My logs are no longer available but the logs provided by others are quite similar to what I was getting when I posted the original bug report.

Richard

this problem is horrible.  after a few days, i have to completely delete ALL of my software repos and then add them back manually, one at a time.

over time:  ERROR.  DOWNLOAD FAILED.  MEDIA EXCEPTION.

still no fix for this grr.

In the FWIW dept...I ran zypper -r  (makes the rebuild rug compatible) and for some reason, I was able to add all of my repos into the database and use it.  Of course, your mileage may vary.   It surprised me but it might be worth a try to see if it is a workaround or I just got lucky.

Apparantly I just got lucky.   It only  worked until I tried to add Guru 10.3.  Then nothing would work.   Even deleting /var/cache/zypp/zypp.db and rebuilding with zypper -r ref worked with that one but it worked well enough to load everything else so I could actually update 3rd party packages from Packman etc.

Well, yesterday I tried to add a comment here, apparently without success. 

I tried your ( comment #20 ) tip with zypper -r and it seemed to work, in that I could add non-SUSE sources again.

Alas I couldn't update, neither using zypper lu nor yast2 sw_single "Package/All in this list/Update if newer version available"

I did succeed to do it with smart though. This is probably the reason they invented smart. yast2 / zypper is broken most of the time. Pity.

True, you better have both :-)

If all fails wget the stuff and then rpm -Uvh.

Yes, but the object is to make SUSE zypper function so it, SuSE,  doesn't depend on external packages.   Now, if they want to make SMART standard, I understand it has some issues also, but it's a thought and perhaps an option.

This bug report gets a bit confusing.

I will mark this as a duplicate of #297627 (as pointed out in comment #18). Please, reopen this bug if you can reproduce with the current factory or beta2, provide clear steps to reproduce and the logs. Thanks a lot for all your help and patience!

*** This bug has been marked as a duplicate of bug 297627 ***