On Thu, Sep 11, 2003 at 12:39:45PM +0200, [EMAIL PROTECTED] wrote: > On Thu, Sep 11, 2003 at 08:21:36AM +0200, Matthias Kurz wrote: > > On Wed, Sep 10, 2003 at 10:36:10PM -0700, Conrad Steenberg wrote: > > [...]
Hi. I also installed an instance as non-root in the meantime. > > > Some suggestions (sorry if it sounds obvious :-) > > Same here. > > > 1. Make sure the openpkg rpm db is intact in the above directory > > 1. Wouldn't really know how to... This is a dir listing, but it's from a > new ins > tall of openpkg: > $ ls -l /ebar/efs1/home1/s01/s011269/openpkg/local/RPM/DB > total 4456 > -rw-r--r-- 1 s011269 s01 24576 Sep 10 11:06 Basenames Same permissions here. > > > 3. Check the permissions of the db directory, your user should have > > > read and write access to the dir. > > 3. DB-dir: > drwxr-xr-x 2 s011269 s01 4096 Sep 10 11:08 DB Same permissions here. > > > 4. Do an 'strace rpm -q openpkg' and send the output, that should show > > > which system call failed (if the problem is in fact a permission or > > > locking problem). > > There is a strace command under Solaris, but it is probably better to > > use "truss". > > strace - print STREAMS trace messages > > truss - trace system calls and signals > > 4. strace doesn't work "ERROR: unable to open /dev/log", but truss does > though (output and some version of this mail can be found here: > http://b0rken.dk/openpkg.txt ) I was sure, that "truss" was meant. Other platforms, other commands. At least for "special" things. > > > 5. Make sure the right version of rpm gets called by your command. > > That is a good idea, because there may be an /opt/sfw/bin/rpm from the > > companion cd. > > 5. Already did that one... To convince you :) > $ rpm --version > RPM version 4.0 > $ export PATH=/ebar/efs1/home1/s01/s011269/openpkg/local/bin/:$PATH I think, the "regular" way is to do a eval `/ebar/efs1/home1/s01/s011269/openpkg/local/etc/rc --eval all env` I don't see something special, there, though. Except that it sets LD_LIBRARY_PATH... i'm sure this makes some sense... But i don't think this is related to your problem. > $ rpm --version > RPM version 4.2.1 > > Could this be a db problem (the program)? Well how did you unpack the openpkg-tool rpm ? You could have used rpm --rebuild <path-to-openpkg-tool>.src.rpm. I tried rpm -ivh <path-to-openpkg-tool>.src.rpm, then i went to the equivalent of /ebar/efs1/home1/s01/s011269/openpkg/local/RPM/SRC/openpkg-tool on my machine and did a rpmbuild -ba openpkg-tool.spec 2>&1 | tee log Hmmm, -bb would have been enough... Then, i added the "binary" package from the equivalent of /ebar/efs1/home1/s01/s011269/openpkg/local/RPM/PKG/ with rpm -Uvh /projects/tmp/non-root/RPM/PKG/openpkg-tool-20030902-20030902.... And it worked. $ rpm -qa gpg-pubkey-63c4cb9f-3c591eda openpkg-20030909-20030909 openpkg-tool-20030902-20030902 What disturbs me, are the strange "platform" parts in the names of the binary packages. I see openpkg-tool-20030902-20030902.ix86-solaris8-ptn.rpm ^^^ I saw "eeh" in your mail. Hmmm, i'd say there is a problem. But it has probably nothing to do with _your_ problem. Did you do something different from what i did ? (mk) -- Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47 >> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) << ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
