Custom Query (344 matches)

Running any yum command on a Japanese OS/2 system, or any language system when SET LANG=ja_JP has been set, results only in an error output similar to the following.

[E:\]yum list updates
Traceback (most recent call last):
  File "/@unixroot/usr/lib/python2.7/site.py", line 550, in <module>
    main()
  File "/@unixroot/usr/lib/python2.7/site.py", line 540, in main
    setencoding()
  File "/@unixroot/usr/lib/python2.7/site.py", line 494, in setencoding
    sys.setdefaultencoding(encoding) # Needs Python Unicode build !

Using yum 3.2.27-6 and python 2.7.6-10.

(IIRC, this seems to be a somewhat different error message than I got under the same circumstances with python 2.6.)

The workaround is to run SET LANG=en_US before running any yum command, but it's difficult for me to ask the user(s) I'm supporting to do that.

Any time the Python interpreter is run while the VX-REXX Designer (VRXEDIT) is open, the Workplace Shell locks up and becomes completely unresponsive.

The only way out is to either reboot, or to use a utility like CAD-Handler in conjunction with XF86SUP.SYS to issue a SIGKILL to force-kill either python.exe or vrxedit.exe; this latter option does not always work.

This problem is 100% reproducible for me on multiple systems.

On rare occasions I have seen what I suspect is a similar hang with other programs (not simply VRXEDIT) but these are not consistently reproducible. In any case I suggest that this be taken as a general Python problem and not a VX-REXX specific one.

(In case it is relevant, I would note that VX-REXX makes heavy use of SOM. I have also occasionally seen a similar hang with Python while running Lucide, which is also SOM-based; might this be a possible clue?)

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.