rtorrent 0.8.3 installation on debian slug

[stanley...@gmail.com]

Yesterday I installed debian(lenny) as the following page described
http://www.nslu2-linux.org/wiki/Debian/HomePage (it doesn't seem to
be working now 11/4/2008 8:30amEST- maybe the page got hacked?)
on my nslu2 (266Mhz,32MB ram). Everything seems running fine.

I tried to install rtorrent by following the instructions of
extracting/uncompressing those three tar.gz files from the other
thread(titled "installation question") from the root directory (/)
after I downloaded them. It went fine. The files/links were there
after I confirmed their creation date.(11/4/2008) under /lib.

When I tried to execute rtorrent by a normal user account here is what
I have on the screen:

$ /usr/bin/rtorrent
-bash: /usr/bin/rtorrent: No such file or directory

Here are some misc info if it helps:

$ uname -a
Linux dishare 2.6.26-1-ixp4xx #1 Fri Oct 10 02:29:27 UTC 2008 armv5tel
GNU/Linux

$ file /usr/bin/rtorrent
/usr/bin/rtorrent: ELF 32-bit LSB executable, ARM, version 1,
dynamically linked (uses shared libs), for GNU/Linux 2.6.12, not
stripped


Any suggestions?
Hopefully I didn't miss any obvious things here..

Thanks!

[Martin Manscher]

Did you set the execute bit? :-)

 

Martin

"I reject your reality and substitute my own" - Adam Savage

2008/11/4 <stanley...@gmail.com>

[stanley...@gmail.com]

That was one of the things I checked after seeing the error message...

$ ls -l /usr/bin/rtorrent
-rwxr-xr-x 1 root root 1253197 Oct 29 18:39 /usr/bin/rtorrent

On Nov 4, 10:50 am, "Martin Manscher" <martinmansc...@gmail.com>
wrote:

> Did you set the execute bit? :-)
>
> Martin
>
> "I reject your reality and substitute my own" - Adam Savage
>

> 2008/11/4 <stanleylan2...@gmail.com>

[hhasert]

You did not say if the root account was able to execute rtorrent. If
the root account can execute it correctly, it must be a problem with
the access rights, either to the file or the directory tree. Unix
allows the 'other' group execute rights to rtorrent, so any user
should be able to start it. Probably /usr/bin is in your path for the
user, so 'which rtorrent' should give you /usr/bin/rtorrent. I cannot
explain the behavior you are seeing, there must be something else we
are missing.

[stanley...@gmail.com]

Here are some of the commands I tried as root. So far I am feeling
this is an issue related to shell/system but I honestly have no clue
where to start.

# which rtorrent
/usr/bin/rtorrent

# whoami
root

# /usr/bin/rtorrent
-su: /usr/bin/rtorrent: No such file or directory
# rtorrent
-su: /usr/bin/rtorrent: No such file or directory
// I guess this means the path variable is correct.

# ls -l /usr/bin/rtorrent

-rwxr-xr-x 1 root root 1253197 Oct 29 18:39 /usr/bin/rtorrent

It got me thinking.. what would be the cause for "no such file or
directory" error msg after I issue a command??
So I tried to issue a non-existing command twice. One with simple
command and the other with /usr/bin path added:

# /usr/bin/sdfk
-su: /usr/bin/sdfk: No such file or directory
# sdfk
-su: sdfk: command not found

Hmmm... interesting. But I still can't figure it out.

[Randy]

Stanley - did you first install rtorrent from the debian repository
BEFORE using Hans' files? If you did not, that may be the source of
the problem. In other words, install the "regular" debian rtorrent
(using, as root, apt-get install rtorrent). This will ensure that the
slug's OS is aware that rtorrent is installed. Then use Hans' latest
version by extracting the tar.gz files over the top of the debian
versions. If rtorrent is not first installed "the normal way", I'm
thinking the OS won't necessarily know how to run Hans' files. Does
that make sense?

Randy

[hhasert]

It might help, but normally the OS itself does not need that kind of
measures. It could be that the SE Linux policy prohibits execution, I
have no experience with that. Installing the official first probably
gives the right entries in the policy configuration, so it might just
help.

[lizardcry]

The "No such file or directory" probably is a result of the big endian/
little endian issue. This compile is big endian, but debian arm is
little endian?

[Martin Manscher]

That would also explain my lacking ability to run the binaries shared here :-)

Martin

-- "I reject your reality and substitute my own" - Adam Savage

2008/11/9 lizardcry <t1x.b...@gmail.com>

[hhasert]

I am running the standard Debian 'lenny' distribution, which is an
upgrade from the 'etch' distribution. There can be no issue on endian-
ess, since the debian distribution for arm runs in little endian mode.
Rtorrent was compiled on the slug itself, no cross compile, debian
distribution, so little endian. Previous compiles were used by many
others and worked fine. Stop the nonsense on endian-ess please, since
obviously you are no expert on the subject.

Still that leaves the mystery on why it obviously finds (the 'which'
command shows that) but cannot execute the file. Has anyone tried to
install the rtorrent package, start rtorrent succesfully and then
copying my files over the package files ? Second remark is that after
installing the libraries, you need to run '/sbin/ldconfig' to have
them linked in the library list (although I would expect another error
message from linux then you get).

[julian67]

I had the same experence as others. I'm not sure that it's possible
to successfully distribute and install Debian binaries this way. It
may be issues with SELinux but it could also be simpler permissions
problems, ACL, user IDs etc. As everybody running Debian Lenny on
NSLU2 is running (near enough) identical hardware and identical
software then this seems one of the rare occasions where distributing
checkinstall debs is preferable to other methods.

[hhasert]

> I had the same experence as others.  I'm not sure that it's possible
> to successfully distribute and install Debian binaries this way.  It
> may be issues with SELinux but it could also be simpler permissions
> problems, ACL, user IDs etc.  As everybody running Debian Lenny on
> NSLU2 is running (near enough) identical hardware and identical
> software then this seems one of the rare occasions where distributing
> checkinstall debs is preferable to other methods.

It is possible, since I use the same mechanism on my own slug. The
distributions might differ, since I upgraded from etch to lenny and
perhaps some other paths were chosen. I agree that it would be better
to have a distribution, but then again you should use the official one
if you need this method. I just provide compiled latest versions for
anybody that wants them, it is not an offical distribution and I have
no intention of becomming a part of one. Still it bugs me why
overwriting the existing executabels suddenly fails to operate, but
nobody reports a set of simple checks/outcomes that help me determine
what the problem might be. I will spend time on it again if someone
with a little linux knowledge describes the scenario.

[Julian Hughes]

I just noticed that rtorrent in its latest version and libtorrent in
a recent version have finally arrived in Debian experimental. I am
installing them now and will post later on how they are working. I
know my .rtorrent.rc file will need quite a lot of changes to make the
leap from 0.7* to 0.8

[Julian Hughes]

On Mon, 24 Nov 2008 09:04:48 -0800 (PST)
hhasert <Hans....@gmail.com> wrote:

>

correction: experimental versions not yet available for this
architecture :-(

[julian67]

.......

> nobody reports a set of simple checks/outcomes that help me determine
> what the problem might be. I will spend time on it again if someone
> with a little linux knowledge describes the scenario.

.......

Can you describe/define what information you seek to permit you to
diagnose the problem? I'm unsure what might constitute "a set of
simple checks/outcomes" and even if *I* was sure it might be, it may
be that *you* are sure it means something else ;-)

[hhasert]

> Can you describe/define what information you seek to permit you to
> diagnose the problem?  I'm unsure what might constitute "a set of
> simple checks/outcomes" and even if *I* was sure it might be, it may
> be that *you* are sure it means something else ;-)

Sure. What I still do not get is if rtorrent was installed from apt-
get and then overwritten by the tar files. I used apt-get install
rtorrent first. That gave me the files that the tar.gz files
overwrite with a newer version. Specifically the library files will
have changed, so check if the following symlinks are there (for
0.12.4) :

-rwxr-xr-x 1 root root 854 Nov 20 22:14 /lib/libtorrent.la
lrwxrwxrwx 1 root root 20 Nov 25 18:52 /lib/libtorrent.so ->
libtorrent.so.11.0.4
lrwxrwxrwx 1 root root 20 Nov 20 22:17 /lib/libtorrent.so.11 ->
libtorrent.so.11.0.4
-rwxr-xr-x 1 root root 1006481 Nov 20 22:14 /lib/libtorrent.so.11.0.4

I might have goofed up during the transition from 12.3 to 12.4 (I have
the libs in /usr/local/lib as well and it hides errors sometimes). If
you have:

lrwxrwxrwx 1 root root 20 Nov 25 18:52 /lib/libtorrent.so ->
libtorrent.so.11.0.3

run (as root):
cd /lib
rm libtorrent.so
ln -sf libtorrent.so.11.0.4 libtorrent.so

run:
/sbin/ldconfig
/sbin/ldconfig -p | grep libtorrent

output should be :
libtorrent.so.11 (libc6) => /lib/libtorrent.so.11
libtorrent.so (libc6) => /lib/libtorrent.so

Try a copy of rtorrent in another location (f.i. your home dir)
cp /usr/bin/rtorrent ~
cd ~
./rtorrent

[uncle...@gmail.com]

Did anyone get this issue solved?

I have the "lenny" install and am able to start the default rtorrent
0.7.9 which comes with the distro but after following all the advice
on this page, still get the "bash: /usr/bin/rtorrent: No such file or
directory"

Will I need to compile it myself as in this website?

http://www.osix.net/modules/article/?id=827

[hhasert]

Unfortunately there are 2 lenny distributions, one the update of etch
and the other the 'armel' version from the RC1 install. The problem is
that they use a different model for executables, so maybe you have the
'armel' version. Mine are compiled with the old lenny version and do
not use 'armel'.
SInce my power supply died on me recently, I will install with the new
lenny 'armel' distribution (I flashed the device first, because I
suspected a flash error). A collegue of mine already has the 'armel'
version and compiled rtorrent with it. I will ask him to send
libtorrent and rtorrent and publish them here also.

[julian67]

On Dec 7, 3:03 pm, hhasert <Hans.Has...@gmail.com> wrote:
> On Dec 6, 3:49 pm, uncletho...@gmail.com wrote:
>
> > Did anyone get this issue solved?
>
> > I have the "lenny" install and am able to start the default rtorrent
> > 0.7.9 which comes with the distro but after following all the advice
> > on this page, still get the "bash: /usr/bin/rtorrent: No such file or
> > directory"
>
> > Will I need to compile it myself as in this website?
>
> >http://www.osix.net/modules/article/?id=827
>

well now we know why your executables don't work for anyone who
installed Lenny, they are for a different architecture. I really
really wish you had mentioned this before......it's important.

[hhasert]

> well now we know why your executables don't work for anyone who
> installed Lenny,  they are for a different architecture.  I really
> really wish you had mentioned this before......it's important.

The problem is that I installed Lenny as well, just from a distupgrade
to Etch. Along the road someone decided to change to 'armel' and still
call it Lenny. I hinted at it before, but I guess I got more focussed
when I needed to reinstall my Slug and saw the RC1 flash image called
Lenny distribution. Apologies, should indeed have stressed it more
clearly. I switched to 'armel' myself now and will clearly mark
updates for 'armel' in the name of the files.

[hhasert]

> The problem is that I installed Lenny as well, just from a distupgrade
> to Etch. Along the road someone decided to change to 'armel' and still
> call it Lenny. I hinted at it before, but I guess I got more focussed
> when I needed to reinstall my Slug and saw the RC1 flash image called
> Lenny distribution. Apologies, should indeed have stressed it more
> clearly. I switched to 'armel' myself now and will clearly mark
> updates for 'armel' in the name of the files.

Another line in my defense, my collegue who switched to 'armel' told
me about problems with the gcc library version and did not report the
problems you have. I will make a topic on how to implement the files I
provide here and a way to check if you have the 'armel' or the regular
version of Lenny. I am going to implement the 'armel' files from my
collegue on my newly installed system, so I will use anything I find
in the comments on the implementation. Just a last check, you did
unzip and untar the files and not just renamed them I hope ?

[julian67]

Naturally I unpacked the files and placed (I hesitate to say
installed) them as advised and followed all the instructions.

Actually this all comes back to the question of packaging and
distribution. I also hadn't considered the difference between arm and
armel architectures even though I'd read about it in passing while
preparing to install Debian on my NSLU2. You may recall that in an
earlier post I suggested using checkinstall on the basis that as
everyone is using the same OS on the same hardware that this would be
one of the few circumstances whern a checkinstall deb would be really
satisfactory. Well now I realise that this is as bad an idea as
distributing a simple tarballed binary and as unlikely to be
successful. I appreciated from your earlier posts that you feel some
resistance to making deb packages, though I can't say I understood
your reasoning, but I suggest that this is the only sensible way to
distribute binaries for Debian with a reasonable expectation of
success and would ultimately involve you in far less, and less
tedious, correspondence ;-)

Anyway my NSLU2 is sitting idle so I think I'll just get on with
building some debs myself. I guess it will take somewhere between 9
and 12 hours to complete (my desktop is amd64 with 64 bit Lenny
installed, apparently cross compiling on amd64 for armel is
problematic so I will compile and build on the NSLU2) and I will post
again if there are any particular problems or unusual requirements you
or anyone else may be interested in.

[hhasert]

> Naturally I unpacked the files and placed (I hesitate to say
> installed) them as advised and followed all the instructions.
>

I expected it, just checking.

> Actually this all comes back to the question of packaging and
> distribution.  I also hadn't considered the difference between arm and
> armel architectures even though I'd read about it in passing while
> preparing to install Debian on my NSLU2.   You may recall that in an
> earlier post I suggested using checkinstall on the basis that as
> everyone is using the same OS on the same hardware that this would be
> one of the few circumstances whern a checkinstall deb would be really
> satisfactory.  Well now I realise that this is as bad an idea as
> distributing a simple tarballed binary and as unlikely to be
> successful.  I appreciated from your earlier posts that you feel some
> resistance to making deb packages, though I can't say I understood
> your reasoning,  but I suggest that this is the only sensible way to
> distribute binaries for Debian with a reasonable expectation of
> success and would ultimately involve you in far less, and less
> tedious,  correspondence ;-)
>

True, but I have no experience in creating deb files. I just wanted to
provide the compiled binaries which take about 12 hours to compile on
the SLUG with a swap partition on a USB stick. If the swap is on the
HD the time to move the disks heads is adding additional compile time.
No sense in all of us compiling the latest revision, so it was just
for grabs. No intention to be a new debian source for it. If you plan
to provide working deb files and/or give me the recipe, I propose to
post them here and save the rest of us the trouble of staring at a
hard working SLUG for a couple of hours.

> Anyway my NSLU2 is sitting idle so I think I'll just get on with
> building some debs myself. I guess it will take somewhere between 9
> and 12 hours to complete (my desktop is amd64 with 64 bit Lenny
> installed, apparently cross compiling on amd64 for armel is
> problematic so I will compile and build on the NSLU2) and I will post
> again if there are any particular problems or unusual requirements you
> or anyone else may be interested in.

I tried to cross compile as well for the non-'armel' version, but I
could not make it work. Oh, it compiled fine in qemu, but crashed on
the SLUG almost immediately. I have not found success stories on the
net, so I decided to compile on the super powered SLUG instead.

[hhasert]

Just downloaded the 'armel' version from my collegue and copied it
over the existing binaries. I can start rtorrent without any problems,
so the method itself works perfectly. Just noticed that this distrib
places the lib files in /usr/lib and only creates one symlink. I will
upload the 'armel' files.

[Randy]

Interesting comments, Hans and julian67. Thanks for posting. I am also
running the armel lenny. I didn't think of the fact that there are 2
different lennys. Hans, I see you uploaded new armel versions of
rtorrent and libtorrent. Do we need an armel version of xmlrpc?

[hhasert]

On Dec 9, 4:11 am, Randy <randy.hasti...@gmail.com> wrote:
> Interesting comments, Hans and julian67. Thanks for posting. I am also
> running the armel lenny. I didn't think of the fact that there are 2
> different lennys. Hans, I see you uploaded new armel versions of
> rtorrent and libtorrent. Do we need an armel version of xmlrpc?

Randy,

No, the 'armel' version was compiled to the standard xmlrpc libraries
on Lenny. I will look into a compile of a newer version of xmlrpc
later on. Drawback is that only 32bit integers will be communicated to
a xmlrpc client. The result is overflows on the larger numbers when a
number is requested from rTorrent. This can be overcome (like I did in
giTorrent) by asking rTorrent to produce a string representing that
number instead.

[uncle...@gmail.com]

Thanks for recompiling got the EL version for lenny which I can
confirm I have.

Only problem is that after following your new installation
instructions, it gives me errors saying it can't find glibc

rtorrent: /lib/libm.so.6: version `GLIBC_2.0' not found (required by /
lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.2' not found (required by /
lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.3.2' not found (required
by /lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.1' not found (required by /
lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.0' not found (required by /
lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.1.3' not found (required
by /lib/libtorrent.so.11)


Do I need to install it?

[julian67]

It might interest everyone to know that libtorrent11 and rtorrent
0.8.4-1 for armel have now arrived in Debian Experimental.

quote:

"You should be able to use any of the listed mirrors by adding a line
to your /etc/apt/sources.list like this:

deb http://ftp.de.debian.org/debian experimental main

Replacing ftp.de.debian.org/debian with the mirror in question. "

and to install is as simple as

# apt-get -t experimental install libtorrent11 rtorrent

You may need to explicitly uninstall the old libtorrent10 and rtorrent
packages.

Using the experimental repository is much simpler and safer than
adding Sid because apt-get or aptitude never automatically installs
packages from experimental and also will not dist upgrade to
experimental packages.

I installed libtorrent11 and rtorrent 0.8.4-1 this way yesterday onto
my Lenny armel NSLU2 and ran rtorrent overnight as usual. The
configuration has changed a lot from older versions and
the .rtorrent.rc has to be reworked to reflect the changes. Back up
your .torrent files before you start the new rtorrent. Most details
can be found at the rtorrent wiki though documentation is incomplete
and much is still outdated. But rtorrent itself works better now.
I've used rtorrent 0.8.3 or 0.8.4 on i386 and find there is less
upload overhead and that all the features do work such as disabling
hashing and moving torrents on completion. Definitely on the NSLU2 I
had better upload speed and less overhead with the new client. No
torrents completed yet so I can't confirm that the move on completion
works. On the old client moving on completion worked but caused the
file to be hashed again, even if hashing was disabled. This in effect
uses all the NSLU2's processing power and makes the system slow/
unresponsive. This is supposed to be fixed now.

[hhasert]

Julian,

Good to know. There are indeed a lot of changes to the rc file and the
syntax for schedule commands have drastically changed. Most of it is
documented on http://libtorrent.rakshasa.no/wiki/RTorrentCommonTasks#Movecompletedtorrents.
Also the Ratio handling has changed, see http://libtorrent.rakshasa.no/wiki/RTorrentRatioHandling.

[julian67]

On Jan 3, 3:15 pm, hhasert <Hans.Has...@gmail.com> wrote:
> Julian,
>
> Good to know. There are indeed a lot of changes to the rc file and the
> syntax for schedule commands have drastically changed. Most of it is

> documented onhttp://libtorrent.rakshasa.no/wiki/RTorrentCommonTasks#Movecompletedt....

> Also the Ratio handling has changed, seehttp://libtorrent.rakshasa.no/wiki/RTorrentRatioHandling.

some torrents completed last night and the move feature worked
properly. Because I wasn't awake/watching I'm not sure if this
initiated a hash check like in earlier versions (even with hashing
being disabled) but sooner or later I will see a file complete and
post what happens (rtorrent runs on cronjob 2300-0800 so it usually
all happens while I'm asleep or not near a PC).

[uncle...@gmail.com]

Hi there, thanks for the news that there is a new version of rtorrent
and libtorrent11 on the experimental branch of debian.

I have tried to install it but I get the same error I got when I tried
to install the precompiled version of libtorrent11 i.e.

rtorrent: /lib/libm.so.6: version `GLIBC_2.0' not found (required by /
lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.2' not found (required by /
lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.3.2' not found (required
by /lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.1' not found (required by /
lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.0' not found (required by /
lib/libtorrent.so.11)
rtorrent: /lib/libc.so.6: version `GLIBC_2.1.3' not found (required
by /lib/libtorrent.so.11)

I have tried to remove libtorrent and try again but it doesn't help.
Is there anyway I can completely uninstall the relevant libraries and
start over again incase I have broken something?

[uncle...@gmail.com]

O.k. I deleted all the libtorrent* files in /lib and reinstalled the
experimental packages and rtorrent starts now, woohoo.

I too will test whether everything works before giving it the thumbs
up.

[uncle...@gmail.com]

Could someone post their new .rtorrent.rc file here? I am having
problems with the on_finished commands which rtorrent is complaining
about. I've looked at the link given but it still doesn't like the
syntax...

[hhasert]

The new syntax looks like this :

system.method.set_key = event.download.finished, link1,
"create_link=base_path,,.finished"

Although rtorrent complains about the old syntax as deprecated, it
still works, so :

on_finished = move_complete,"d.set_directory=
$d.get_custom1= ;execute=mv,-u,$d.get_base_path=,$d.get_custom1="

The new syntax will look like the first one, but the guys did not want
to document the new syntax for moving files, because 0.8.4 is not
stable yet. Probaby the new systax looks like this :

system.method.set_key = event.download.finished,
move_complete,"d.set_directory=$d.get_custom1= ;execute=mv,-u,
$d.get_base_path=,$d.get_custom1="

No guarantees though, have not tested this !

[uncle...@gmail.com]

O.K. I will keep the old syntax for now then as long as it still
works. I will report back if it works.

[uncle...@gmail.com]

Hi there, just reporting back that all seems to be working and
rtorrent definitely seems a little nippier than the older version I
had. Thanks for all the help.