Sourcery fails to install successfully created packages

[mimosa]

I normally use slapt-src, but just installed a couple of packages using Sourcery. The packages worked fine when I installed them manually, but Sourcery itself tells me:

Code: Select all

Slackware package /usr/src/slapt-src/desktop/q4wine/q4wine-0.114_r1-i486-1_SBo.txz created.

sh: spkg: command not found
spkg -u --reinstall --install-new q4wine-0.114_r1-i486-1_SBo.txz Failed


I uninstalled this [in fact, not this, but icoutils; but the problem was apparently identical] and reinstalled using slapt-src, without having the same problem. I don't normally use Sourcery, so it may just be something silly I'm doing wrong.

[Shador]

Do you have spkg installed? What's the output of:

Code: Select all

slapt-get -search 'spkg-*|pkgtools-*'

Probably spkg should be a dependency of slapt-src or even better a fallback for pkgtools.

[mimosa]

Yes, I already checked this:

Code: Select all

root[vanilla]# slapt-get --search 'spkg-*|pkgtools-*'
pkgtools-13.37-noarch-9 [inst=yes]: pkgtools (The Slackware package maintenance system)
spkg-1.0-i486-1gv [inst=yes]: spkg (package manager)

Also it worked fine on the command line; presumably slapt-src uses the same commands as Sourcery, in this case, following the Slackbuild?

EDIT

Incidentally, it seems another user didn't have any problem installing the same packages using Sourcery:

http://www.salixos.org/forum/viewtopic.php?f=16&t=2972&p=18875#p18875

... so it's probably not a bug in Sourcery.

[laprjns]

Incidentally, it seems another user didn't have any problem installing the same packages using Sourcery

I didn't have any problems installing those two packages using sourcery either. Maybe you forgot to update sourcery first, before building the packages.

[mimosa]

Does Sourcery need to be updated separately from slapt-src? it worked with slapt-src. Surely Sourcery is just a graphical front end for the command line tool?

... just tried installing a random package, same thing, so I guess it affects all of them. Just to be safe I updated both in console and using Sourcery's menu, but the install failed with the same error. slapt-src was successful.

It does look like this is a local problem, not a bug, and since I can just use slapt-src, it's not an inconvenience. However, it's odd.

Also the actual error is strange. spkg *is* present.

Could it have anything to do with the fact I'm using Ratpoison? I can't really see how though.

EDIT

The exact command mentioned in the Sourcery log worked when I uninstalled one of the packages and reinstalled manually:

Code: Select all

root[vanilla]# cd /usr/src/slapt-src/development/icoutils
root[icoutils]# spkg -u --reinstall --install-new icoutils-0.26.0-i486-1_SBo.txz
Installing package icoutils-0.26.0-i486-1_SBo...

[Shador]

Are you running slapt-src as root? Is your path set properly? Try running gksu xterm and check PATH there, also try running the slapt-src command from that window.
And yes slapt-src is a graphical frontend for slapt-src.

[mimosa]

Solved - though I don't fully understand why. I called Sourcery by doing

Code: Select all

: exec ktsuss sourcery

but when called using the Ratpoison menu, it works normally. So I guess ktsuss doesn't give all the needed root privileges. The menu uses gksu, and :exec gksu sourcery also works. So I was calling Sourcery in the wrong way.

[Shador]

ktsuss probably doesn't update the environment properly, especially path. There might be an option to change that behaviour, check with ktsuss --help.

[mimosa]

Well, I think I'll use gksu in future. Thanks Shador and laprjns, and sorry for the false alarm

Just found this post:

viewtopic.php?p=6616

... so is gksu just a wrapper for ktsuss precisely to avoid this problem?

See also this short post, which describes the problem exactly:

http://mike.opennix.com/2010/07/ktsuss- ... ware-13-1/

ktsuss gives the app it calls root privileges, but if that app in turn calls apps that need to be run as root, they don't inherit the privileges. In this case, that was spkg.

[gapan]

... so is gksu just a wrapper for ktsuss precisely to avoid this problem?

Not only that. It's also a replacement for the standard (and now obsolete) gksu tool.