Forum: The Testing Area
Topic: February Extensions
started by: roberts
Posted by roberts on Feb. 04 2007,01:40Now posted in unc area:
Now posted in the testing area
Posted by roberts on Feb. 09 2007,05:42acpid.unc now in unc area. Thanks Juanito
frostwire.uci now in testing area. Thanks Wdef
Posted by WDef on Feb. 09 2007,17:30I'm looking forward to seeing how aria2.uci stacks up against my thusfar all-time favorite linux downloader, prozilla.dsl (or ProzGui.dsl) :=)
One thing though: aria.uci's user.tar.gz contain a symlink from /opt/aria2/bin/aria2 to /usr/bin/aria2.
This isn't a good idea because that symlink won't work unless mkwriteable has been run previously (ie another .dsl has been installed) and part of the idea of uci extensions is to avoid running mkwriteable as far as is possible.
Perhaps the maker might want to symlink that binary into /opt/bin? This is a better way to put it in PATH.
Posted by nickelplated on Feb. 14 2007,20:16Here's the latest stable version of Tor
< http://www.featureset.org/tor-0.1.1.26.dsl >
< http://www.featureset.org/tor-0.1.1.26.dsl.info >
< http://www.featureset.org/tor-0.1.1.26.dsl.md5.txt >
Posted by Felson on Feb. 15 2007,18:58Emacs 21.4
< http://www.myte.ca/dsl/emacs-21.4.dsl >
< http://www.myte.ca/dsl/emacs-21.4.dsl.info >
< http://www.myte.ca/dsl/emacs-21.4.dsl.md5.txt >
I also have a UNC version of this, but it is just made useing dsl2unc anyway.
Posted by roberts on Feb. 15 2007,19:45Now posted in the testing area:
alsa-oss_1.9rc4.dsl - Thanks WDef
tor-0.1.1.26.dsl - Thanks nickelplated
Posted by meo on Feb. 17 2007,18:09Dear Felson!
Thanks a lot for making the emacs extension for DSL. I have been yearning for it a long time and the one you made works like a charm. So, Thank You!
Have fun with the wonderful DSL distro,
Posted by roberts on Feb. 18 2007,07:39Now in the testing area two more extensions from Juanito.
Posted by WDef on Feb. 18 2007,12:27O good, ntfsprogs. That might come in handy. Thx.
Re: frostwire.uci - I've noticed with dsl-2.1b that after running frostwire downloading for about 20 mins, java sometimes starts hogging up all the cpu ->99%
Someone told me that frostwire's code-parent Limewire on Windows sometimes does this also.
Is Java normally a cpu pig, or this is likely to be a bug ...
Posted by ^thehatsrule^ on Feb. 18 2007,16:23
I wonder if ntfsprogs is "stable" enough for everyday use?
Posted by Juanito on Feb. 19 2007,04:32[quote=^thehatsrule^,Feb. 18 2007,15:23]
I compiled the latest version - apparently since 1.13 it is much better and after all, I resized an ntfs partition on my own hd with it...
But you're right - to be used with care.
Posted by jls legalize on Feb. 19 2007,18:45I've declobbered the eciadsl optional so now the system doesn't crashes, u can find it < here >
abolize narcotic laws
lagalize cannabis, etc
Posted by WDef on Feb. 21 2007,13:17alsa-oss_1.0.9rc4.dsl was missing some soname symlinks.
The fixed version has been forwarded to Robert, pending posting in the repo a tar.bz2 archive of extension+checksum+info file can be downloaded < here >
Posted by roberts on Feb. 21 2007,20:06I just processed a batch of extensions:
In the testing area:
An updated extension in the net area:
A new module in the modules area:
Updated extension in the system area:
Updated extension in the gtk2 area:
gnumeric.dsl info file only
Be sure to read the info files for details.
Thanks to all for their contributions.
Posted by roberts on Feb. 24 2007,20:03New in the testing area:
Be sure to read the info files for details.
Thanks to all for their contributions.
Posted by jls legalize on Feb. 25 2007,16:53I've made a new version of teamspeak client, u can find it< here >
legalize cannabis, etc.
Posted by WDef on Feb. 25 2007,20:50Pending posting in the repo, < here's > a bz2 tarball containing mutella-0.4.3.dsl
This might help those unable to run java-based gnutella clients like Limewire/Frostwire. Not tested much.
Salient points from the info file:
Sometimes very slow to connect on first run -
takes 10-30mins on my connection, so be patient,
but once up it's fine. The knack to using this
seems to be learning both the terminal commands
(only need 'info' 'find whatever.mp3' 'get' and 'exit'
for basic use, and the web browser GUI for managing
downloads. Don't expect something as easy as Limewire-
Frostwire but it works and there's no java!
I've added fresh GWebCaches as there were no defaults.
When these die you can update them in the config file
from eg < http://gcachescan.jonatkins.com/ >
See < http://mutella.sourceforge.net/readme.php >
for setting username/password to the GUI, opening the GUI
for remote connection etc.
I got carried away with the startup script and it will
get your external ip and set it in the config file, since
I had an idea that might speed things up.
Note mutella has a peculiar interaction with its config file
- you must use the 'set' cli command to affect most configurations
and mutella will overwrite some in the config file (eg IP) as
it pleases and not others, which need manual editing.
Built from binary rpm using aliendebs with debian dependencies
Posted by WDef on Feb. 25 2007,22:42Oops! - fix for some silliness if you try to start mutella while it's already running:
< http://www.megaupload.com/?d=H1447D8M >
Posted by Zucca on Feb. 27 2007,04:53Thanks. =) I'll join as a beta-tester.
Posted by Felson on Feb. 27 2007,17:42Just wondering, but is there something wrong with the emacs extension? Would be nice if it could make it into the testing area so I can find out if there are bugs in it that I haven't found.
Posted by roberts on Feb. 27 2007,19:17mutella-0.4.3.dsl now in testing area. Thanks WDef.
Posted by roberts on Feb. 27 2007,19:21Felson, I have not seen emacs in the email to email@example.com
If you want it downloaded instead of emailed, let me know that too.
I don't just grab/download extensions unless requested.
Posted by Felson on Feb. 27 2007,21:26Thanks Robert.
I tried submitting it that way, but I think it was to big for my outgoing email... Anyway, I think I have a better way to submit it useing the email anyway.
Posted by MakodFilu on Mar. 01 2007,02:43
I should add that upon installing ntfs-progs.dls, xtdesk was killed and mydslPanel refused to load.
I noticed /usr/lib/libstdc++.so.5 was symlinked to a nonexistent libstdc++.so.5.0.7 (5.0.5 shoud be right?)
I am unsure if this issue is ntfs-progs.dsl related or that I abused (grin) so much my system upon installing a batch of games.
Posted by ^thehatsrule^ on Mar. 01 2007,06:50I did mess around with the libstdc++ 5 before, and since xtdesk depends on that library, if the library is properly "messed up" the app cannot run.
(btw, did you mean mydsl or dslpanel or..? - might be the same problem though)
An easy way to check would just to ztvf the archive (if this doesn't show the links, you could just extract it to a temporary dir). But, of course, this should be a task that the package maintainer should look at if what I wrote is confusing :P
Posted by MakodFilu on Mar. 01 2007,14:53
Confirmed. Maybe 5.0.7 is in 3.3 RC1 where it is not in 3.2?
All in all, again, a really welcome addition. Thanks, Juanito (I messed up the quoting in the previous post)
I uploaded my first DSL extension also, netwide assembler for all. =) Hope I did not too bad with packaging it.
Posted by Felson on Mar. 01 2007,17:17I had the same problem with some extensions I am playing with makeing. 5.0.7 comes from the gcc-with-libs or gnu-utils.
Posted by Juanito on Mar. 01 2007,19:50libstdc++.so.5.0.7 is added by gcc1-with-libs, since I would have compiled with this loaded I guess this is why the ntfsprogs symlink points to it. I confirm ntfsprogs wipes out the desktop icons because of this.
Before I re-post ntfsprogs.dsl - I thought it might be a good idea to check on the "correct" way to modify the package:
On boot, without loading any packages, /usr/bin/libstdc++.so is set up in DSL as follows:
# ls -l /usr/lib/libstdc++.*
/usr/lib/libstdc++.so.5 -> /KNOPPIX/usr/lib/libstdc++.so.5
/usr/lib/libstdc++.so.5.0.5 -> /KNOPPIX/usr/lib/libstdc++.so.5.0.5
# ls -l /KNOPPIX/usr/lib/libstdc++.*
/KNOPPIX/usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.5
/KNOPPIX/usr/lib/libstdc++.so.5.0.5 is a file, not a symlink
gcc1-with-libs.dsl only contains one /usr/bin/libstdc++.so file:
ls -l /ramdisk/tmp/gcc1-with-libs/usr/lib/libstdc++.*
my initial ntfsprogs.dsl package contained the following symlink:
ls -l /ramdisk/tmp/ntfsprogs/usr/lib/libstdc++.*
/ramdisk/tmp/ntfsprogs/usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
From all of this, I guess the correct thing to do would be to delete the lib/libstdc++.so.5 symlink in the ntfsprogs package and let it use the default DSL symlink.
Could somebody confirm that this is the correct assumption?
Posted by WDef on Mar. 03 2007,01:07I can't recall having any particular problems with that lib while gcc1-with-libs was installed, so ..
Since you compiled ntfsprogs against the newer lib, I'd be inclined to include the newer lib from gcc1-with-libs and its soname symlink in the ntfsprogs extension and overwrite the older library. This would probably be a definite must if (? - I haven't checked) there are headers for the newer lib in gcc1-with-libs and these got included during the compile.
The convention is that newer minor releases of libraries are not supposed to break applications that depend on older versions, so it should be ok (this rule doesn't always seem to work, but that's the theory).
You could try just using the existing older version of the library on the system. People keen to strip a few kB from extensions might say testing this is a must.
Since this is an extension that could do real harm if it goes wrong, I'd be inclined to play it safe and include dependant libs that match those present during the compile if headers got included.
Posted by ^thehatsrule^ on Mar. 03 2007,02:38I would agree with WDef that if you compiled against the 5.0.7 library, you should use that instead and be on the safer side.
However, with a quick look at the (current) ntfsprogs.dsl in testing, it seems like
- it doesn't need libstdc++ at all (using ldd, it seems like it only needs libc)
- you can strip out "libntfs.la" (afaik .la files are useful for recompiling)
Posted by stupid_idiot on Mar. 05 2007,15:51
Thanks WDef - I never knew that. I was always putting all my symlinks in /usr/local/bin. Will get on it soon.
Edit: HEY! /opt/bin is not in the default path for user 'dsl' on 3.2RC3. How's the news from 3.3?
Posted by WDef on Mar. 05 2007,22:05
You might want to report that in the releases section if no-one else picks up on it here.
Posted by roberts on Mar. 05 2007,23:30Both /opt/bin directory and in user DSL path for v3.3RC2.
Available real soon now.
Posted by ArthurII on Mar. 16 2007,20:46Hi, I wish to download wvdial.dsl ; where do I need to go to to do this?
Posted by Juanito on Mar. 17 2007,04:12From < http://distro.ibiblio.org/pub....testing > - next to hsfmodem.dsl