Error starting deluge, found bug reports
 

Okay, I have been having some problems with Deluge. I only installed it a couple of days ago, and at first I could not get it to build. (Details are on this thread.) I was using the Deluge and Libtorrent source linked on SBo (deluge-1.3.5 and liborrent-r7459). bartgymnast told me those versions have issues together and helped me get it built with deluge-1.3.6 and libtorrent-rasterbar.

Now, however, I am getting an error when I try to start Deluge. It says it will not start in classic mode, and gives this:

If I turn off classic mode and try to start in the other mode, it starts, but will not connect to anything.

So I found some information about this, but I am not sure what to do with it. It looks like this is a known bug that is related to boost:

http://dev.deluge-torrent.org/ticket/2300

https://bugs.archlinux.org/task/34478

However, in the second link, it says it's fixed. But I have a question about this. Why is this bug report on the Arch site? Why would the Arch developers fix a bug in a C library? Does this mean it is only fixed for Arch? Forgive my ignorance, but I am still learning how all this works.

Anyway, now I know about the bug, but what should I do? If I understood the answers to the above questions I might be informed enough to judge, but now I am uncertain. Is the bug fixed in some other version of deluge? Or should I try to get an older version of boost and replace the library I have with it? Would that be a good idea, or will it break something?

Should I submit another bug report, and if so, where?

I would be thankful if someone more experienced could give me guidance how to proceed. Thanks!

Your error, "ImportError: dynamic module does not define init function (initlibtorrent)" is different from the one(s) in the bug reports you linked.

Therefore, you have a different problem.

Selecting the phrase I quoted and googling for that results in hits that suggest that you haven't met all of Deluge's dependencies.

Good luck.

Wow, I see that now. Thanks for pointing that out. What happened there was that I copied and pasted the entire error into Google, and it said that the search string was too long (strange, because it isn't saying that now). Then I copied about the first half of the traceback and came up with the error from the bug report. I looked at it and thought it was the same, especially since it was also about Deluge not starting in Classic mode, but I did not read that very last line so I guess I was wrong. Sorry about that.

Anyway, doing a diff on those two errors, it seems they are identical except for that very last line, and also mine referencing the /usr/lib64 directory instead of /usr/lib. Doesn't it mean something that everything else is the same? I would be very happy if this were only a dependency problem, but the first thing I did when I wanted to install this was make this list of the dependencies from Slackbuilds.org:

I then installed everything, starting from the set on the farthest indent and working my way out (i.e pysetuptools, zope.interface, MarkupSafe, pyOpenSSL, python2-chardet, pyxdg, python-twisted, and Mako). I have not yet blacklisted those packages on Slackpkg, so when I run a slackpkg clean-system, you can see them all there (attached).

Or course, these dependencies are for deluge-1.3.5 and liborrent-r7459, and as I said in my first post, I had to use different versions to get it to build. Maybe those other versions require newer versions than what I have here? How can I find out?

Thanks for the help.

At the top of the traceback it says something about 'most recent calls are last'. Since you're interested in what was happening when it died that's where you look. Also, generally error messages are more interesting, informative, and googleable than tracebacks, that's where I started googling.

It means that deluge died in roughly the same area of the code in both. Since deluge was telling you that it couldn't start, then it died, this isn't too surprising.


That looks like the right approach for that version of the software.

I'm sorry, I haven't read your other post very closely and only dropped in because this thread wasn't getting any replies.

The way to start to check those dependencies is to see if there is a Changelog on the respective site(s) of the software you're compiling. If so, examine the changelog to see if any mention is made of library upgrades.

If that doesn't seem to help then google, using the terms deluge, the deluge version number, lib<libname>, and then something like 'initlibtorrent error' to see if that gets any hits.

Next try looking at the makefile(s) of the software you're compiling to see if any specific library version is mentioned in there.

Glad to, but this isn't really very good help. I don't have a 64-bit system and I don't use deluge, so you're not getting much beyond general here's-how-I-do-it advice.

Thank you for answering my questions. Honestly I found that extremely helpful. Even if it doesn't directly solve my problem, it helps me understand what is going on so that I can solve problems in the future.

I tried all of the things you suggested and unfortunately nothing worked. I checked the changelogs for Deluge and all of its dependencies, and could not find any mention of a change in library versions. I found nothing on Google either. I am using only the build scripts from SBo and not makefiles, but I looked in those and found nothing helpful.

I see that SBo has other versions of both libtorrent and libtorrent-rasterbar. I still don't know what the difference is. I also do not know what the difference would be if I built libtorrent as a separate package and installed it, or built it as part of Deluge, as I have been doing. If anyone could tell me what the difference would be, I would appreciate it.

In the meantime I am going to try to build Deluge with some other libtorrent versions, and also build libtorrent and libtorrent-rasterbar on their own and install them (one at a time, I guess, until I learn what the difference is between them and if they should be installed concurrently), just to see if that helps. I hope I don't break anything.

The guy having the same error message in this thread (http://forum.deluge-torrent.org/view...aecf1&start=10) eventually solved his problem, which was having multiple versions of libtorrent installed and the wrong one was being used.

Since you're installing multiple versions (and have already installed them, if I'm reading correctly), this could be your problem, too.

Again, if I'm reading other sites correctly, libtorrent has one version of libtorrent and libtorrent-rasterbar has a different version of libtorrent and a small program bundled with it.

It works!

No, I had not already installed different versions of libtorrent. I would not want to install more than one at the same time. I just wanted to see if replacing the version of libtorrent I had with a different one would solve the problem.

The issue was that when I first tried to build Deluge with the Slackbuild on SBo, it linked to deluge-1.3.5 and libtorrent-r7459. But I could not get it to build with those sources. So I opened a thread and someone suggested using deluge-1.3.6 and libtorrent-rasterbar-0.16.11. Libtorrent-rasterbar was supposed to work and was referenced as working in other sources. It did build. But then I couldn't run Deluge due to this error.

I just tried several combinations of Deluge/libtorrent/libtorrent-rasterbar versions, and the combination that worked was libtorrent-0.13.0 and deluge-1.3.6. I could not get it to work with any version of libtorrent-rasterbar.

I just have one more question, if you'll tolerate it. If I were to download the source and slackbuild from here: http://slackbuilds.org/repository/14...es/libtorrent/ it would build a libtorrent package. But if I were to download the stuff from here: http://slackbuilds.org/repository/14.0/network/deluge/, it would build a deluge package using the libtorrent AND deluge source. Can you tell me what this means, really? Would it still create the same libtorrent libraries if either one of those packages were installed?

Just hoping to understand this. Thanks again!

can you share the deluge.slackbuild and the files that you use please?, im having the same issue.

I welcome them, because then I'm passing on the ability for you to help yourself and sharing a bit of my hard-won knowledge besides. ;v)

Those two statements are true. The first way you'd compile (the slackbuild does this) and package (the slackbuild does this, too) a slackware package that would install libtorrent, any accompanying documentation the packager chose to include, and that's all. The second would compile libtorrent, then compile deluge, then package up both, along with anything else the packager wanted to include, and you'd end up with a slackware package that would contain and install the pair as (supposedly) a working application in one package. Either way is acceptable, but slightly different implications.

The implication of the libtorrent package is that you get a libtorrent that several other things could use, -or- that you're installing a specific libtorrent version (perhaps the latest, perhaps not) that you specifically need.

The implication of the second is that you end up with a working application and its dependency(ies), whether or not anything else can use that particular version of libtorrent.

Sort of, and no at the same time. See the numbers following the names and links of the source files? ( libtorrent-0.13.0.tar.gz (d499178f72010d5067a77f41fa1a1505) and libtorrent-r7459.tar.xz (871fb322dd0bf5233479b9cf895c04ac) )

Those numbers are the md5sum (a checksumming (easy description) program) of the source files. Those numbers are used to verify that the file on the server and your download of it are identical.

I just downloaded libtorrent-47459.tar.gz and then ran:
Notice that I got the same number? That means that I my download gave me an exact copy of the file on the server. No line noise or other wonky-ness corrupted the file coming to me. yay! ;vD

Now notice that the numbers (quoted above) following the two libtorrent .tar.xz files are different? That means that those two files are different and that means that the two libraries are almost certainly different versions.

Why "almost certainly?" you ask? Good question!

The .tar means that the file is an archive (like a zip) created with tar (Tape ARchiver). If the contents of the two .tars are identical except for a single character (like an extra carriage return somewhere in the source) then the md5sums would be different, likely very different, but the two sets of sources _could_ compile to exactly the same code.

The .xz indicates the compression program used. .gz uses gzip, .bz uses bzip(?), and .xz uses xz.

Now, the -r7459 in the second libtorrent file name is _likely_ (but not certainly) a "revision number" in some source code control system (or versioning system like subversion, mercurial, git, bazaar, or similar).

_That_ tells us that they're targeting a very specific commit in the life of libtorrent. Likely not a full release like 0.16.0, or 1.10.9, or 23.10.2, but just a commit to the version control system that the libtorrent developers didn't feel was important enough to do a build, version number update, and release from.

If you have any other questions feel free to ask. I've been doing this programming thing for 40+ years through minis, micros, mainframes, Windows, Unix, AIX, embedded systems, and now a bit of Linux. Fun stuff.

EDIT:
So, sort of in that they're both libtorrent and no in that they're different versions of libtorrent, with different deletions, changes, and additions, making them potentially very, very different in requirements and function.

EDIT2:
In fact, that whole initlibtorrent thing working in one version and not the other goes to show how different they are!

Jamesf,

Thank you, that makes perfect sense. I appreciate your willingness to share your knowledge! I am just getting started in my exploration of programming, and Linux is a hobby (right now). I hope to have such an understanding myself one day.

So in the case of building the Deluge package and libtorrent with the same Slackbuild (the second way), the package would not be listed in /var/log/packages, correct? If so, then I wonder why it would be done that way? Wouldn't that make it harder to see what you have installed on your system, and to upgrade something if necessary? Why not just have libtorrent listed on SBo as a dependency (like Deluge's other 6 dependencies), instead of writing it into the build script?

Addendum: Now I am confused. Right before I got Deluge working by (I thought) building it with a different version of libtorrent (instead of libtorrent-rasterbar-0.16.11 or libtorrent-r7459, which were not working), I installed the standalone package libtorrent-rasterbar-0.16.3 and it's dependency, GeoIP. I wanted to see if that would make a difference for the error I was getting. It didn't.

I thought I had removed libtorrent-rasterbar-0.16.3 when it didn't work, but in fact I did not. I then decided to build Deluge with deluge-1.3.6 and libtorrent-0.13.0. That built, and when I installed it, it worked with no error. So at this point, I unknowingly had two different versions of libtorrent on my system, and it worked perfectly.

When I discovered what I had done, I removed the standalone package libtorrent-rasterbar-0.16.3. If I follow your explanation correctly, this should have left only the libraries for libtorrent-0.13.0 (which was built with the Deluge Slackbuild that I altered to use this version) on my system. When I did this, Deluge again would not start correctly.

So I thought maybe Deluge needed libtorrent-rasterbar-0.16.3 (and not libtorrent-0.13.0) in order to work. But I did not want two versions of libtorrent on my system, so I removed the deluge package (containing libtorrent-0.13.0) and then built Deluge with libtorrent-rasterbar-0.16.3. When I installed it, it again gave me the error. At this point I had tried both versions of libtorrent separately, but every time I had only one version of libtorrent installed, deluge would not work; when I had them both, everything was fine.

To confirm this, when I reinstalled the Deluge package containing deluge-1.3.6 and libtorrent-0.13.0 and also the standalone package libtorrent-rasterbar-0.16.3, it all worked again.

I hope this has not been too hard to follow. I have tried to be precise to avoid confusion, but in doing so I fear I have written the word "libtorrent" so many times that my narrative will be difficult to read.

The short summary is that it seems to me Deluge will only run when I have two different versions of libtorrent on my system: one that I built Deluge with, and one that I installed as a standalone package. Surely this can't be right. I think I have to figure out what is going on here or I will never understand Linux package management. Can you give me any hints?

P.S. In case you want to ask, yes, I did leave libtorrent-rasterbar's dependency GeoIP during these trials in case that was needed (even though it is not listed as a dependency of Deluge). I tried both with and without it.

@cisneros: I have attached my Slackbuild. You can get the rest of the details of what I have done from this thread. Please let me know if you can get it to work with one version of libtorrent, or if you need both as I seem to. Good luck!

it worked, i think the correct order is installing the libtorrent rastebar pkg, then compile and install deluge with libtorrent 0.13.0, then remove the deluge folder in .config, now is working. is not a pretty installation but its working.

In my case the order was not important. It works with those two versions of libtorrent installed. What I am wondering is why both are necessary.

if you go to the about screen of deluge, you can see that the libtorrent version is 0.16.11.0, so it is using the rasterbar version.. kind of weird, but if you check the tar files, the two are very different. so if you see it like those two are different libs i think its correct... duno.

Hmm. It looks like I made a typo in my post #10 about the package number and consequently you are using a different version of libtorrent-rasterbar than I am. But yes, if I go to the about screen in Deluge, it says it is using libtorrent version 0.16.3.0, which is my version of rasterbar.

Still, If it were only using the reasterbar version, then I would think it should function with only that version built in. But as I said in my post #10, it does not. It seems to want be built with some libtorrent and then have libtorrent-rasterbar as a standalone package, even though it is not listed as a dependency. That is what I am not really understanding.

yes, it is indeed weird, maybe the slackbuild just need to be updated.

Glad to help. I started in Slackware by installing and spending a lot of time reading here and in /usr/doc/Linux-HOWTOS and /usr/doc/Linux-FAQS. More in Linux-HOWTOS, btw. ;v) The first time I ssh'ed in from work, started an X program running on my home machine with the output window on my Windows work machine was quite a day for me. :v)

Also /usr/doc/_program_name_ (take a look!) contains documentation, help files, sometimes a little, sometimes a lot, for various things installed on your system.

Not quite. All installed packages get listed in /var/log/packages. The package tools handle doing this and also update /var/log/removed_packages, too. Thinking of a package as either a program _or_ a library is incorrect. One of your packages installed libtorrent (and likely .h files, documentation files, etc.) while another installed deluge and a specific libtorrent that that version of deluge was supposed to require.

Open /var/log/packages/bsd-games-2.13-i486-12 (on my system, bsd-games-whatever on yours). This package contains the programs under /usr/games as well as the man pages for those programs, etc. You're looking at a list of everything installed and where it went by opening the package log.

A package is merely an installable archive of files (like a tar or zip file) with a description file (the .desc file) and a script file (doinst.sh) that does everything specific that the enclosed files need to have done to be considered installed. Like, for instance, the $PATH modified, or .desktop files exposed to xfce and/or kde, or specific groups created, specific users created, or specific permissions set, or files moved, renamed, or deleted.

*EDIT: What makes it an installable archive? Simple, it is an archive in the format understood by the package management tools written specifically for Slackware by the creator(s) of Slackware. Those tools, installpkg, upgradepkg, removepkg, have been improved over the years and now understand .txz files as packages. A few years ago only .tgz files were understood to be packages. Other Linux distributions use "package" formats specifically created/designed by their particular package tools: yum, pacman, emerge, etc. END OF EDIT*

Some packages include everything needed for a particular program including, but not limited to, man pages, program file(s), necessary libraries, info pages, .desktop files, etc.

Some packages install only libraries, some install (like some slackbuilds.org packages) only the program, relying on a base slackware install to supply the necessary libraries.

However, all of them supply a list of all of the files that they've installed. That list is tacked on after the contents of the .desc file in /var/log/packages/_package_name_.

To see the contents of a package file you can use explodepkg (man explodepkg) to extract the contents of the package into a subdirectory without installing the package.


As you've discovered, not all libtorrents are created equal. Further, even if deluge said "go get the libtorrent slackbuild" that doesn't mean that the libtorrent authors haven't moved past that version of libtorrent. Some groups, after updating their library, remove the old version from public view.

Think about it this way: libtorrent guys release version 1; slackbuild maintainer makes a slackbuild for libtorrent v1; deluge guy modifies deluge to use libtorrent v1; slackbuild maintainer makes a slackbuild for deluge and says, "Go get libtorrent from sbo, use that"; everyone is happy. Now the libtorrent guys make significant changes and release v1.1 and, since they don't support v1 anymore, remove v1 from public view. Deluge is now broken for anyone trying to build and install it but still works (of course) for anyone who has already installed it. Now new downloaders can't get the libtorrent version that deluge uses since libtorrent v1 has been replaced by v1.1 and v1 is no longer available.

This sort of stuff really happens. It has happened to me.

Further, if deluge was compiled against a specific commit in libtorrent's version tree instead of a release version then telling people how to get that specific version is a lot more difficult. Remember, the libtorrent maintainer on sbo might not be the deluge maintainer on sbo. And even if he is then he has no control of libtorrent releases and release strategies, or deluge releases and release strategies.

There's a lot that might be going on there.

Consider the following:
Ignore the .a and .la files for the moment, though they are used in compiling and thus are important to you when you figure out what happened with deluge.

The -> indicates that the file name on the left is "linked" to the file name on the right. The file name on the left is only another name for the file name _and_the_file's_contents_ on the right. For our purposes anything without the -> in the line is a simple file with real contents and not a link. You can read up on soft links and hard links and their differences if you want to later. The implications for rm are a little different for the two types of links.

If I ask for libcurl I get libcurl.so, which points to libcurl.so.4.3.0. I can ask for libcurl version 2 (libcurl.so.2) and I get libcurl.so.2.0.2. If I ask for libcurl.so.2.0.3 I haven't got it, nor any 2 version other than 2.0.2. Similarly for versions 3.0.0 and 4.3.0. If I compile against any libcurl version I end up using the same .a and .la files to do it, so presumably all libcurl versions are similar enough to do that.

Except for compiling the situation is similar for libdb_cxx. Notice how all the links go similarly except for the specific .a and .la files. Apparently 4.4 and 4.8 are different enough that if I need to use either specifically then I also have to compile and link against .a and .la files specific to those versions.

Hopefully you can now cat the files under /var/log/packages dealing with libtorrent, libtorrent-rasterbar, and deluge and figure out what installed what and then ls -l /usr/lib/libtorrent* to see what might be getting used.

*EDIT2: You could also 'grep libtorrent /var/log/packages/*' to see all occurrences of the phrase libtorrent in any package listed in /var/log/packages. You could also 'grep libtorrent /var/log/removed_packages/*' to see any libtorrent version you removed. You could also 'grep -l libtorrent /var/log/packages/*' to see only the file names (package names) that contain the word 'libtorrent' in /var/log/packages. Note carefully that in the last case you might get a file name listed where that file contains the phrase "requires libtorrent". A word to the wise, YMMV, standard disclaimers apply, etc. END OF EDIT2*

You can't tell for sure of course unless you examine the contents of the .tar.gz files (the source code, makefiles, etc.) that you downloaded, extracted, compiled, and made into a package with the help of the .slackBuild files. Remember, the programmer can reference libraries during compiling and running in different ways with different results.

Hope this helps, or at least gives you a few places to start! ;vD

An exercise in soft links:
Now you try it, and then understand what happened. A hint: > to a file deletes the file and recreates it. >> appends to the end of the file. Hint 2: @ following a file shown in a simple ls indicates that the file is the left side of a link -> shown with ls -l

Jamesf,

Thank you so much for that excellent tutorial. I am still working through figuring it out as it relates to what I have on my system. I have gone through it and done everything you showed me, but it is not immediately obvious what is going on, so I will have to look for a bit more information and try again in a couple of days. I am currently a college student and I just got a couple of intense assignments (my programming languages class has a heavy workload!), so even though I would much rather spend the day fiddling with Slackware, I have to do what they tell me. :|

I will try again in a couple of days and let you know what I find. I just wanted to say thank you and tell you how much I appreciate you taking the time to explain all of that, especially the linking of libraries. That is the sort of basic functional component of Linux that I want to know more about, but rarely come across in all of my study (and there has been quite a bit of that). I think perhaps I have been looking in the wrong places. I will definitely try /usr/doc/Linux-HOWTOS and /usr/doc/Linux-FAQS.

Since Deluge is fixed, I am marking this thread as solved. I will come back and update when I know more about what happened with it on my system. Thank you again!