setup.py in .tar.gz doesn't work

[Michael Mauch]

Hi,

the setup.py from http://launchpad.net/remote-help-assistant/helper/0.1.2/+download/remote-help-assistant-access-0.1.2.tar.gz uses 100% CPU to search for a non-existent debian/changelog. strace shows a very long upwards path ../../../../../../ (and so on) being accessed. So I edited setup.py, removed that loop and hardcoded the version number. Alas that didn't help much - now I get:

# ./setup.py
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: no commands supplied

The README.txt doesn't say what I should do now (in fact, it didn't even tell me to start setup.py).

I guess I'll copy the share folder to /usr/local/share and the bin folder to /usr/local/bin - ok?

I used the .tar.gz because I'm using Gentoo on my desktop, but probably it's the same problem with the .tar.gz on Ubuntu. Thank you for creating Remote Help Assistant, a secure and easy way to help friends and family is really needed.

Regards...
  Michael

[Andrew Sayers (andrew-bugs-launchpad-net)]

Thanks for this report, and apologies for the delay in getting back to you. It is indeed the same in Ubuntu, and the problem should be fixed in the new 0.1.3 release - could you have a go and let me know?

Apparently, the proper command is "./setup.py install" to install the assistant. I've added that to the README file now. This is my first Python project, so I'm rather learning this stuff on the job :)

Speaking of learning on the job, can I ask what other conventions you're used to as a Gentoo user, that the assistant doesn't currently follow? For example, would you expect setup.py to do dependency tests - to check whether VNC/SSH servers are installed, etc.?

[Paul (b01)]

Double-clicking setup.py in Gnome causes a high cpu use loop till I kill it.

[Michael Mauch (michael-mauch)]

The problem seems to be the same with the remote-help-assistant-access-0.1.3.tar.gz - the loop is still looking for the non-existing file debian/changelog (then ../debian/changelog, then ../../debian/changelog and so on). There is a file PKG-INFO, maybe you wanted to read that? I don't understand why you search in the directories above - the file should be in the current directory, not somewhere above, no?

In Gentoo we use so-called "ebuilds" to install packages. An ebuild has a list with the dependencies, so dependency checking in setup.py should not be needed. An ebuild is separate from the upstream package - it's just a recipe that tells the Gentoo package management where to fetch the package and how to (build and) install it.

I attach an ebuild for remote-help-assistant-access-0.1.3.

[Andrew Sayers (andrew-bugs-launchpad-net)]

Argh, you're right. Could you guys have a go with the attached version of the assistant?

Michael, could you also try the .ebuild file I've included in the package? It's slightly different to your one - some cosmetic changes that make it easier to manage, and the 'copyright' and 'changelog' files are now included in the documentation. By the way, I take it that Gentoo's "openssh" package includes both the client and the server?

[Michael Mauch (michael-mauch)]

Your updated ebuild nearly worked, though I had to rename it to remote-help-assistant-access-0.1.4.ebuild and also re-tar the tar.gz so that it extracted to the remote-help-assistant-access-0.1.4 directory instead of remote-help-assistant-access-0.1.4~bug332711r1 (and of course the automatic download of the remote-help-assistant-access-0.1.4.tar.gz did not work because it is not there yet). I guess the ~bug332711r1 appendix is just some launchpad artifact.

Updated ebuilds could have a -r1, -r2, -r3 attached (like remote-help-assistant-access-0.1.4-r1.ebuild), but more complicated file and directory names make things more complicated (you'd have to stick a line with S="${WORKDIR}/unpacked-directory-name" into the ebuild at least).

The copyright and changelog were also copied to the correct directory.

The "setup.py install" also worked, and I found in another ebuild that we could use "python setup.py install --root="${D}" || die" to copy everything to the sandbox install directory (and let setup.py do what it's supposed to do; I'm not sure what that is, though). I still got a /usr/lib/python2.5/site-packages/remote_help_assistant_access-0.1.4_bug332711r1-py2.5.egg-info, so some part of my renaming didn't quite work, it seems.

Yes, the openssh package on Gentoo always has client and server.