update no longer works

[guzzi]

E:\>yum update
netlabs-exp 100% |=========================| 1.3 kB 00:00
​http://rpm.netlabs.org/experimental/00/i386/repodata/primary.xml.gz: [Errno 9] Requested Range Not Satisfiable
Trying other mirror.
​http://rpm.netlabs.org/experimental/00/i386/repodata/primary.xml.gz: [Errno 9] Requested Range Not Satisfiable
Trying other mirror.
Error: failure: repodata/primary.xml.gz from netlabs-exp: [Errno 256] No more mirrors to try.

After running Yum clean all:

E:\>yum update
netlabs-exp 100% |=========================| 1.3 kB 00:00
netlabs-exp/primary 100% |=========================| 416 kB 00:01
​http://rpm.netlabs.org/experimental/00/i386/repodata/primary.xml.gz: [Errno -1]
Metadata file does not match checksum
Trying other mirror.
​http://rpm.netlabs.org/experimental/00/i386/repodata/primary.xml.gz: [Errno 9] Requested Range Not Satisfiable
Trying other mirror.
Error: failure: repodata/primary.xml.gz from netlabs-exp: [Errno 256] No more mirrors to try.

[Yuri Dario]

It works from here. It seems netlabs is not reachable from your side.

Please try to browse the repository using Firefox at this URL:

​http://rpm.netlabs.org/experimental/00/i386/

[guzzi]

I can browse the repository.

I reinstalled using the bootsrap package, ran a yum clean all, then yum install yum and it worked again. Then I ran yum install qt4-devel-kit, checksum errors after the downloads and nothing got installed. Yum recommended running yum clean metadate, which I did, and I'm back at where I was:

F:\home\default>yum update
​http://rpm.netlabs.org/experimental/00/i386/repodata/primary.xml.gz: [Errno 9] Requested Range Not Satisfiable
Trying other mirror.
Error: failure: repodata/primary.xml.gz from netlabs-exp: [Errno 256] No more mirrors to try.

yum.log contains:
Jan 03 18:03:01 Erased: yum-metadata-parser
Jan 03 18:03:01 Erased: yum
Jan 03 18:04:50 Installed: yum-metadata-parser-1.1.4-3.oc00.i386
Jan 03 18:04:50 Installed: yum-3.2.27-5.oc00.noarch

rpm.log:
/var/log/rpmpkgs {

weekly
notifempty
missingok

}

[guzzi]

Looks like exactly the same problem as in ticket 34

[David McKenna]

I had this exact same problem...

I was having some trouble with a couple apps after I installed the latest libc064 using YUM. In the testing I did to track the problems down, at one point I extracted the libc063-csd3 archive over the libc064 files in \usr\lib. This seemed to correct the problems I was having with the apps, but then YUM started giving the exact same kind of errors you mention. I was not able to use YUM for UPDATE or INSTALL, but some commands (LIST, CLEAN) did work.

I replaced the libc064 files in \usr\lib (from a backup), ran YUM CLEAN ALL, then rebooted. After reboot YUM worked fine.

Maybe just a coincidence but since then I have been able to use YUM with no trouble. The problem apps I put a copy of the old libc063.dll in their directory and start them libpathstrict with Rich Walsh's Run!l with good results.

HTH

[guzzi]

I also replaced the libc064 forwarder dll with the original libc063 dll a few weeks ago. I'll try the same as what you did, might very well be the cause. Hope that some day libc064 gets fixed... Thanks for your input!

[guzzi]

Replaced the original libc064, yum works again after a clean all:-)

[Yuri Dario]

which files did you replace exactly?

[guzzi]

I replaced the libc064 supplied libc063 forwarder dll with the one from the libc063csd3 package. I now have replaced that with the original libc064 supplied one again.
I replaced the libc064 supplied dll because some software, in my case Luckybackup, doesn't work with libc064.

[Yuri Dario]

this is strange, I use libc063 forwarder here, and it works well.

[dmik]

I use the libc063.dll forwarder here too and it works well too.

Are you guys sure you have no real (non-forwarder) libc063.dll already loaded into memory when you see these problems with libc064 and its libc063 forwarder? The thing is that eCS is shipped with the real libc063.dll and unless you make sure that X:\ecs\dll doesn't come before X:\usr\lib in LIBPATH you may have the real libc063 loaded early at boot time by various eCS utilities.

You may check which DLLs are in memory with

pstat /F >log.txt

and then searching for "libc" in there.

[dmik]

That is, the real libc063.dll is not fully compatible with the real libc064.dll and they can't currently work together (various types of problems, needs to be investigated deeper).

[David McKenna]

\usr\lib comes before ecs\dll and os2\dll in my LIBPATH statement (in fact it is first after the period). I have also removed the libc06* files in ecs\dll.

I should point out that YUM works fine as-is. It is only if you copy a 'real' (non-forwarder) libc063.dll over the forwarder in usr\lib (I know... don't do that!) and reboot that the problems with YUM begin.

The reason I (and guzzi) did this is because we noticed odd problems with some apps after upgrading to libc064. I noticed that the CUPS web interface would no longer list any printers to install with libc064, but not libc063. Also, SeaMonkey? would hang with the new ODIN 0.8.2 + Flash with libc064 but not libc063. guzzi had other issues.

I now put a copy of a 'real' libc063 in the SeaMonkey? directory and start it libpathstrict and it works great.

I guess this ticket should be closed since there is no problem with YUM after all...

[guzzi]

Same here. And perhaps open a ticket on libc064. Dave Yeo also reported problems with libc064 when building Mozilla apps. He builds against libc063 because of that.

[dmik]

Okay, I see. Another guilty person may be libc064x.dll shipped with Samba (which has some 063 compatibility issues as well; I had to build my own libc064x back then in order to solve them). So try to stop Samba to make sure its libc064x.dll is not loaded in memory and try the forwarder 063 again to see if it helps.

Anyway, this defect is not the perfect place to discuss it indeed.

[David McKenna]

No SAMBA running here. There IS a libc06B4.dll running (I believe added by the Innotek FT2LIB 2.6 beta1). Hmmm... I wonder if the 2.4 version uses that? I'll check it out...

BTW, thanks for the pstat /f clue... very useful!

[dmik]

Yes, please try to make sure there is ONLY the official libc064.dll from Knut and its libc063.dll forwarder in memory.

On my system it's the case and it works w/o the problems you describe (and on the Yuri's machine too). It means that something is still different and this is the culprit. What if you use the latest firefox 8 instead of seamonkey?

[David McKenna]

I removed Innotek FT2LIB 2.6 and installed 2.4 so now libc06b4.dll is gone. Deleted SeaMonkey? and Firefox as affected apps in the registry. I don't notice any difference with either though...

[guzzi]

Steven Levine might have tracked down the bug in libc064. See ​http://svn.netlabs.org/libc/ticket/255

[Yuri Dario]

This is caused by binary mode flag to be set only for libc 0.6.3 dlls, while 0.6.4 linked dlls does not inherit it (because python executable is linked with 0.6.3).
Fixed in today python rebuild (libc 0.6.4 based).