Custom Query (344 matches)

I am experiencing a series of severe problems with my RPM and YUM installation. To keep this ticket manageable I will open separate tickets for the different symptoms; however, they all began simultaneously and I suspect they are symptoms of a common underlying cause.

Starting from after 'yum clean all' has been run, attempting to run yum for any operation requiring access to the netlabs-rel repository (in this example, 'yum list updates') produces the following on the first attempt:

>>> yum list updates
netlabs-rel                                                 | 2.9 kB  00:00
netlabs-rel/primary_db                                      | 770 kB  00:07


[Errno 2] No such file or directory: '/@unixroot/var/cache/yum/netlabs-rel/e77ab
85162768c38023c339f7c1fc8aa85450df3347f1e19a0c03aa00a3e2512-primary.sqlite.bz2'

Any subsequent attempt to run the same command produces:

http://rpm.netlabs.org/release/00/i386/repodata/e77ab85162768c38023c339f7c1fc8aa
85450df3347f1e19a0c03aa00a3e2512-primary.sqlite.bz2: [Errno 14] HTTP Error 404 -
 Not Found
Trying other mirror.
Error: failure: repodata/e77ab85162768c38023c339f7c1fc8aa85450df3347f1e19a0c03aa
00a3e2512-primary.sqlite.bz2 from netlabs-rel: [Errno 256] No more mirrors to tr
y.

Network connectivity is fine. I can browse the netlabs-rel repo and download files using my web browser without trouble.

My yum.conf contains (comments removed):

[main]
cachedir=/var/cache/yum
logfile=/var/log/yum.log
plugins=0
exactarch=0
obsoletes=1
sslverify=1
metadata-expire=1d
recent=14

My netlabs-rel.repo contains:

[netlabs-rel]
name=Netlabs Stable Repository $releasever - $basearch
baseurl=http://rpm.netlabs.org/release/$releasever/$basearch/
enabled=1

I was previously able to circumvent this failure by manually downloading e77ab85162768c38023c339f7c1fc8aa85450df3347f1e19a0c03aa00a3e2512-primary.sqlite.bz2 from netlabs-rel using a web browser and manually unpacking it with bzip2 in /var/cache/yum/netlabs-rel; however, as of today this file no longer seems to be present on the server. (Even when I was able to do this, it only resulted in another failure mode, for which I will open a separate ticket.)

This appears to have started when I updated rpm to rpm-4.8.1-23.oc00.pentium4 and python to python-2.7.6-11.oc00.pentium4 (along with various dependencies). I should note that most of my other installed packages use the i386 architecture; I had recently added a 'platform' file for UI testing purposes, and didn't notice that the pentium4 arch was being installed until afterwards. Whether this is relevant or not I don't know.

I have attempted to install rpm and rpm-libs version 4.8.1-22.oc00.i386 by manually downloading and unpacking the files into /usr, but this does not improve matters.

It turns out that the /@unixroot/usr/include/paths.h header installed by libc-devel contains incorrect _PATH_* definitions (added there by Knut). It assumes that essential system tools are installed in /@unixroot/bin while Yuri decided to drop this dir in favor of /@unixroot/usr/bin (which in fact contains all these tools).

Now we need to either get /@unixroot/bin back (e.g. as a symlink pointing to /@unixroot/usr/bin) or fix the paths.h definitions in our libc-devel.

There are some programs that provide debug packages (those ending with -debug). These packages are meant to contain .dbg files for each .exe and .dll` file which are the extraction of the HLL debug info from the executable.

The current scheme of creating these packages is inconsistent: on one hand it implicitly creates .dbg files for each .exe/.dll of each RPM that is built, on the other hand the package maintainer needs to manually add the respective sub-pkckage directives to the .spec file.

This needs to be sorted out and automated as much as possible.