Python on DSL
Forum: Other Help Topics
Topic: Python on DSL
started by: dafunks
Posted by dafunks on June 07 2007,14:07
Hi, I use my xbox for Linux and it is using X-DSL which is based on Damn Small Linux 2.1RC2 I would love to setup Sabnzbd on it and just leave it on so I can download from usenet. The xbox does not use much power and they only cost around £20 now so it is a great small system... Just a shame it is not updated to the newer versions of DSL
Would it be easy to setup Python on it and would it be easy for someone who is sort of new to DSL and Python to get working.
Also is there easy ways of getting it working using MyDSL or Apt-get?
Thanks for any help
| Quote | ||||||||||||||||||||||||||||||||
This is a list of things needed to get it working. I took it from a post on the subject. I think it is using a debian linux so not sure if it is the same on DSL. - Dependencies in [] are not needed with python-2.5 - [o) Python-2.4.4] < http://www.python.org > o) Python-2.5 < http://www.python.org > o) CherryPy-2.2.1 < http://www.cherrypy.org > o) cheetah-2.0rc7 < http://www.cheetahtemplate.org/ > [o) elementtree >= 1.2.6] < http://effbot.org/downloads/ > - Required for post processing - o) unrar >= 3.6.6 < http://www.rarlab.com/rar_add.htm > o) unzip >= 5.5.2 < http://www.info-zip.org/ > o) par2cmdline >= 0.4 < http://parchive.sourceforge.net/ > (Optional:) o) yenc module >= 0.3 < http://sabnzbd.sourceforge.net/yenc-0.3.tar.gz > [o) cElementTree >= 1.0.5] < http://effbot.org/downloads/ > o) feedparser >= 4.1 < http://feedparser.org[/QUOTE] > Posted by dafunks on June 10 2007,15:21
Can anyone help?
Posted by mikshaw on June 10 2007,20:15
Python is pretty easy to get into DSL. There are at least a couple versions of it available in mydsl. If you need development libraries, the mydsl might not be sufficient (i'm just guessing). In that case you could install python and python-dev with apt. Or you could install from source. It compiles easily in DSL when using gcc1-with-libs (.dsl or .unc)I have no idea what Sabnzbd is...I'm guessing it has nothing to do with your question.... Posted by dafunks on June 13 2007,14:05
Thanks for the reply.Sabnzbd is a Usenet NZB downloader. It uses just the normal Python version you download. I did try to compile it but it took forever and i waited 5hs and it was still going and as I am using a xbox and the fan is busted right now it was getting too hot so i had to turn it off. I tried using apt but i could not see python 2.5 on there. Posted by mikshaw on June 13 2007,17:43
You could try the python2.5.unc package from the mydsl repository, but I don't think it will work on XBox unless X-DSL has been updated to DSL3.1 or newer
Posted by stupid_idiot on June 14 2007,16:57
I just compiled a python-2.5 uci. Basically, two directories: Keep the read-only stuff in /opt/python-2.5, and let the directory for user-installed stuff be /opt/python-2.5_site-packages. How does python find it? Just replace /opt/python-2.5/lib/site-packages with a symlink to /opt/python-2.5_site-packages.So, I've done the above, plus some extras such as symlinks in /usr/lib for libpython2.5.so* so you can compile stuff that needs to find the python shared lib. As well as the obligatory symlinks in /opt/bin for the python binaries plus a /usr/bin/python symlink, of course. Will send this uci in soon! Posted by dafunks on June 15 2007,23:33
Cool. I think X-DSL can use UCI's but I have had some problems in the past.And your right X-DSL has not been updated since 2005 sadly. Would love it to be. If i knew how id update it. But as I cant even get python 2.5 working not sure id be able too Posted by stupid_idiot on June 17 2007,05:01
Have tried installing cheetah, cherry as well as bittorrent stuff (Twisted, zope-interface, etc.) with the uci and so far seems to work okay.From testing, it seems packages will need to write to $PREFIX/bin,include, and share. So I think I will make a directory called /opt/py25 and put all the writable dirs in there. So we have: /opt/py25/bin [<100K] /opt/py25/include [<600K] /opt/py25/share [unused, 0K] /opt/py25/site-packages [only a README, 4K] And that's about it. Also, zlib in DSL is a few versions behind (1.1.4) and I am getting a 'undefined symbol' error when I try to run BitTorrent with python. The error goes away when I replace zlib with a recent version (1.2.2). Since I can't replace DSL's zlib I will put the newer zlib in /opt/python-2.5/lib and use rpath linking on the python libraries.. I'll keep you guys posted. Maybe some screenshots by tomorrow. Posted by stupid_idiot on June 20 2007,06:28
Very sorry, I couldn't spend any time with Python yesterday. Here's a screenshot, more later:This is SABnzbd: < http://farm2.static.flickr.com/1217/574056473_97e43b76cf_o.gif > This is BitTorrent: < http://farm2.static.flickr.com/1118/573951991_4b573d8715_o.gif > Will try to get python-2.5.tar.gz sent to extensionsATdamnsmalllinux.org by tonight. EDIT: Very busy currently, but should be able to send completed extension in a few days. Posted by stupid_idiot on June 27 2007,02:14
Hello,python2.5.uci has been submitted and will take from a few days to a week to be tested and uploaded. Very sorry to keep you waiting. I hope you'll like it. Posted by dafunks on June 29 2007,13:40
I still cant see it in UCI. Any time on when it will be?
Posted by lucky13 on June 29 2007,13:58
After it's been through testing. It's still in testing:< http://distro.ibiblio.org/pub....testing > Posted by Juanito on July 25 2007,10:18
I've been struggling for a while to make hplip work using Roberts python.uci extension - it compiles without problems to /opt/hplip but then none of the hp-* python functions work. I just remembered your post and realised this is possibly an issue of the /site-packages folder or libraries or both - I'll try and modify the python.uci extension with a symlink to test the site-packages theory. (I suppose that if everything were compiled in /usr/local this problem would not exist.) I like the idea of compiling to /opt/whatever but it's a real pain in terms of libraries, headers, etc - is there a smarter way to deal with this than symlinks to /usr/bin-lib-include and/or adding /opt/whatever/bin to the path (which is anyway limited to the terminal window in question)? Posted by mikshaw on July 25 2007,15:29
Have you tried to see if the Python 2.5 package will work?As far as I know, older Python mydsl packages are only runtime files, which probably means compiling programs with them isn't going to be successful even if you make the directories writable.
Personally I'm not at all into using symlinks in /usr/bin-lib-include. These directories are initially read-only in DSL. I like to try keeping them that way, and also prefer the convenience and safety of not needing to mess with the base system (of _any_ distro) unless absolutely necessary. Most changes of this kind can be made to files in your home directory, keeping system files untouched. Modifying variables may be limited to the current terminal, but only if you make those changes from a terminal window. Your startup scripts (.bash_profile, .bashrc, .xinitrc) are there to allow you to make these changes before you open an interactive shell. You can export the PATH variable from /home/dsl/.bash_profile to include /opt/whatever/bin, and never need to do it manually. Even if that directory doesn't exist (if you don't have the related extension installed at the moment) it's still in PATH for future use. The same can be done with the LD_LIBRARY_PATH for finding libraries. Another option is to create your symlinks in /opt/bin instead of /bin, /usr/bin, or /usr/local/bin. This directory is already writable and in PATH. The limitation with this is /opt/bin is at the _end_ of path, which means you cannot override a system executable with your own by adding it to this directory. But there are ways to deal with that, too, such as creating /home/dsl/bin and adding that to the _beginning_ of PATH. Also, use aliases. Aliases are extremely handy, not only for allowing you to run commands easily that are not in PATH, but for running complex or cryptic commands with a few keystrokes (alias nocomment='egrep -v "#|^ *$"'). The limitation here is that aliases are limited to your shell, and are ignored by most other applications. As far as headers go, I think that is dependent on what you're compiling and how it is compiled, but the only time you need to bother about them is while you're compiling, so it's not such a big deal. When using headers installed in /opt/myapp/include for a C program, typically do "export CFLAGS=-I/opt/myapp/include" before compiling, and "export LDFLAGS=-L/opt/myapp/lib" if there are libraries that are not available in DSL base. In a typical source package with a configure script, "configure --help" will generally tell you what variables apply. I guess you could probably export these variables from a startup script the same way as PATH, though it never occured to me to try it until this moment. But as I said, it's only important while you are compiling. Posted by lucky13 on July 25 2007,16:42
Veering off on a tangent...I don't understand a blanket objection to using a file hierarchy like /usr/local that's specifically intended for applications and libraries added locally, particularly if those things are to be shared among all users on a Unix host. I also don't understand not using symlinks to do what they're intended to do (see below). Per the FHS standard,
< http://www.pathname.com/fhs/pub/fhs-2.3.pdf > I realize Linux doesn't adhere to stricter Unix standards, so /usr/local is used variously throughout Linux distros. Red Hat's use of /usr/local:
< http://www.redhat.com/docs....hs.html > In contrast, Debian doesn't install anything to /usr/local to comply more strictly with FHS. Per Debian's documentation, "Debian packages must not use that directory[/usr/local], since it is reserved for system administrator's (or user's) private use." < http://www.debian.org/doc/maint-guide/ch-modify.en.html > I kind of understand the rationale used to justify your position in the sense that the CD/frugal are read-only, but you parenthetically added "_any_ distro" and I don't understand why /usr/local would be avoided in a standard installation. Otherwise, developers need only fill /usr/bin with apps and not even make a /usr/local directory hierarchy except to be compliant with FHS (like Debian does). Many distros even advise setting /usr/local in a separate partition because it's intended to be a unique-to-the-system directory hierarchy; Slackware comes to mind in this regard -- if there are more than two standard / and swap partitions available during setup, the installation script prompts to see if the user wants to put /usr/local on its own partition. Never mind that /usr/local is the default prefix for most source you'll ever compile. I know DSL is a little different because of extensions like UCI and UNC and because /opt is used in frugal for persistent partition, but that doesn't obviate the reasons for why /usr/local exists. It shouldn't be avoided as though it were sacred ground. I don't use aliases to take the place of symlinks, and I don't use symlinks to take the place of aliases. I don't think they should be considered equivalents even though I accept you can find more than one way to skin a cat. An alias would require a full path, a symlink allows a standard call without calling with an atypical path (which would make an alias using whatever is linked even easier since it doesn't require the atypical path to be included). Symlinks reroute to sensible, typical paths. Aliases are intended to reduce complex commands into simpler keystrokes, such as the example you gave. Finally, I don't understand your concern about convenience or safety other than your ideas keep things a little more compartmentalized with respect to what's on the CD versus what you add -- which doesn't sound too appealing to me because my systems are mine, not a developer's. It's still no more secure adding a link to any other directory in PATH like /opt/bin than it is in /usr/local/bin -- same net effect. Posted by ^thehatsrule^ on July 25 2007,19:46
it is getting off-topic, but I'll respond here...All 3 quoted use of /usr/local basically say the same thing... the quotes for RedHat and Debian applies to their package management (which corresponds as expected). /usr/local is for the local sysadmin, and not for official distributed packages of the distro. Hence why the default compilation path in source tarballs is usually in /usr/local
Posted by lucky13 on July 25 2007,20:09
His statement was much broader than that: "...also prefer the convenience and safety of not needing to mess with the base system (of _any_ distro) unless absolutely necessary..." There may be circumstances in which it's impractical to use symlinks, but those are exceptions to the rule. It's certainly not a bad, unsafe, insecure, or inconvenient idea for standard hard drive installs (of "_any_ distro"). (edit: fixed punctuation) Posted by stupid_idiot on July 25 2007,21:17
Yes, but since there are already so many symlinks in /usr/local/bin to start with, I think it's less confusing for certain extensions to limit their symlinks to /opt/bin. For example, below are the symlinks belonging to Wine - it is obvious that those symlinks that begin with 'wine-' are from Wine, but some things are more confusing, like 'function_grep.pl', 'uninstaller', 'wmc', or 'wrc'.
I agree with you that whether you use /usr/local/bin or /opt/bin, the program will still run. I would argue that putting an extension under /opt/package_name is more convenient for the purpose of removing the software - `rm -rf /opt/package_name` will do - as opposed to separately removing /usr/local/bin/files, /usr/local/lib/files and /usr/local/share/files. The latter is very easy to do if you have the experience, but I think it will be difficult for a newbie. In contrast, if I use /opt/package_name, once I delete this directory, only the symlinks are left. These will become broken links - I think broken links are shown with a different colour from normal links when running `ls`, IIRC. The counter-argument is that this can be done in /usr/local also - the following can be done when configuring the software package when compiling: `./configure --prefix=/usr/local/package_name` For a .dsl package, this is possible. This can be done if the extension author chooses to do so. Anyway, due to conventions in DSL, .tar.gz seems to imply that the package will be self-contained, whereas if you are downloading a .dsl, the expectation is to have files scattered all over /usr/local. Please forgive me if the above sounds incoherent - It is very early in the morning (just got up). Posted by mikshaw on July 25 2007,21:54
It was not a recommendation of what I think should be done, nor a suggestion that the symlinks are a bad idea, but merely my personal preference. It is a choice to limit whatever configuration possible to my own home directory in all distros I use. This allows me to easily port my settings, symlinks, and whatever else makes the system easier to handle, to other distros, saving me from having to recreate the same symlinks and wrappers every time I try a new distro or upgrade an existing one (I tend to install fresh rather than upgrade...just another personal preference/habit). The "safety" relates to the fact that limiting changes to my home directory means I have no concern about complications that might arise from tweaks and experiments. If I mess something up, the worst case would require only starting with a fresh home directory.In the case of sharing with other users I agree it would be a different issue, but one I did not bother to bring up. In all honesty I don't believe more than a few people here are in a situation where they admin a multi-user system, and those that do don't have any reason to listen to me ramble on about things they already know (and probably have better/different ideas about). The main point, however, was to suggest that there is no smartest way to handle files installed in /opt, but that there are various methods to choose from. Some methods might be more appropriate depending on the situation, so it would be useful to understand some of the differences between them. I did not intend to imply that others should do things the way I do them, although the term "use aliases" does sound more imperative than I had intended. Posted by mikshaw on July 25 2007,22:01
Posted by lucky13 on July 25 2007,23:18
Mikshaw
I was a little more concerned about the implication that symlinks are somehow undesirable, insecure, inconvenient, or unsafe, especially with respect to /usr/local. The part about /usr/bin-lib-include I certainly understand and agree with.
That's an understandable assumption (especially with dsl). ------ s_i:
Heh. Serves you right for trying to run Windows programs under Linux. Posted by mikshaw on July 26 2007,02:27
In the case of deleting directories or unmounting uci packages, a usable alternative to a symlink is a wrapper script. I use wrappers for several of my frequently used ucis. The wrapper first checks for the existence of the executable before trying to run it. In some cases, the wrapper chooses a different executable if the desired one is not found. For example, this checks for the vim uci package, but runs vi if it's not found:
The .dsl packages install in the standard unix/linux locations, which to many people might appear to be a mess. There is a logic to this, though, since grouping similar file types together allows for much quicker access to executables and shared resources (fewer directories needed to search for libraries, headers, and executables). Comparing this to Windows, for example, it is much easier to run an arbitrary command without needing to know where it is...Windows needs a full path to work in most cases. That said, I'm not a huge fan of this logic when it comes to complex programs that include many files. In those cases I'd rather have a self-contained package (or nearly so...shared libraries would be the exception) that can be easily moved, removed, or updated without the need to search for support files. The binary releases of Firefox and Blender are good examples of this. Posted by Juanito on July 26 2007,18:53
Well, that certainly looked like a case of light blue touchpaper & stand back...Interestingly (or not), compiling hplip and python to /usr/local did not solve the lib problem - "/usr/local/lib/cups/backend/hp" complained about various missing libs requiring linking them one by one /usr/local/lib -> /usr/lib. But... compiling hplip to /opt/hplip and python to /opt/python worked after I copied the contents of /opt/hplip/lib/python2.3/site-packages to /opt/python/lib/python2.3/site-packages and all this without needing to link libs anywhere (but adding /opt/hplip/bin and /opt/python/bin to the path). |
Ikonboard © 2001 Jarvis Entertainment Group, Inc.