September Extensions

Forum: The Testing Area
Topic: September Extensions
started by: roberts

Posted by roberts on Sep. 01 2007,15:42

xorg72setup.tar.gz is now posted in testing.

Thanks goes to ^thehatsrule^

Posted by roberts on Sep. 05 2007,21:51

Updates to hplip extension:
hplip_etc.dsl
hplip_site-packages.tar.gz
python-2.3.uci

And a new info file too.

Thanks goes to Juanito.

Posted by Juanito on Sep. 07 2007,17:51

I'm working on moving the samba.dsl extension to /opt - before I get too far with this, a couple of questions:

1. Hopefully this is OK with JB4x4 and Roberts?
2. I plan to move the extension to /opt/samba-2, does this make sense?
3. I plan to put samba.conf in /etc/samba-2, does this make sense?

If this is OK, I'll aim to make a samba-2.uci

Posted by stupid_idiot on Sep. 11 2007,08:37

In all versions of 'wine-0.9.4x.uci' up to current, the truetype fonts were built using fontforge 0.0.20041218 (Debian Sarge). This version of fontforge has a problem which causes generated fonts to be invisible under Wine. More at:
< http://wiki.jswindle.com/index.php/Fonts#Invisible_Fonts >
I will get a newer version of 'fontforge' from sarge-backports, regenerate the font files, and then resubmit 'wine-0.9.4x.uci'.
Thanks for reading.
Update:
Yes, the newer version of 'fontforge' from sarge-backports fixes the problem. So, 'wine-0.9.4x.uci' will be resubmitted shortly. Thanks!

Posted by roberts on Sep. 11 2007,19:18

New or updated extensions now posted!

Thanks to J.S. for:
moc.uci
rtorrents.uci
wine-0.9.4x.uci

Thanks to Juanito for:
xorg72-dev.tar.gz

Thanks to lucky13 for:
calcurse.uci
screen.uci

Posted by roberts on Sep. 11 2007,19:23

Juanito wrote:

Quote

...Hopefully this is OK with JB4x4 and Roberts?

Sure. Anyone can update or re-create any extension that I have made. Actually I created the first few extensions to be used as examples for the community. I would rather see the extensions remain the primary domain of the community.

Posted by jls legalize on Sep. 12 2007,02:23

Fair, but why dsl donations aren't partially redistribuited to mydsl optional extensions builders and forum/wiki/dsl irc chat users who help more?

legalize cannabis, coke, opium. :angry:

Posted by stupid_idiot on Sep. 12 2007,08:35

Hey - that would dilute the spirit of volunteerism.

p.s.
(On a totally unrelated note)
Roberts, did you receive my email with 'mplayer.uci' and a few other extensions, about a week ago?
Thanks alot.

Posted by curaga on Sep. 12 2007,16:53

I just found my busyserver.tar.gz has dhcp spelled as "dchp" in the .info-file's description area, it's fine in the other occurrences though. Would you mind Robert changing it?

Posted by roberts on Sep. 12 2007,20:49

Quote

Roberts, did you receive my email with 'mplayer.uci' and a few other extensions, about a week ago?
Thanks alot.

I updated mplayer.uci on Aug 4. I believe the others were info file updates. Let me know if this is not the latest.

Posted by roberts on Sep. 12 2007,20:51

Quote

I just found my busyserver.tar.gz has dhcp spelled as "dchp" in the .info-file's description area

OK. Done!

Posted by stupid_idiot on Sep. 13 2007,05:32

Hi Roberts:
I've forwarded my original email to extensions@damnsmalllinux.org. Could you please check for it?
Thanks.

Posted by roberts on Sep. 16 2007,05:04

codecs-qtx.uci
codecs-real
codecs-win32.uci
codecs-wmp.uci
mplayer.uci
mplayerplug-in.dsl

Now posted. Thanks to J.S.

Posted by stupid_idiot on Sep. 16 2007,13:34

Plan for this week:
- Touch up the 'cdisplay' script ('cdisplay.tar.gz')
- Submit 'unace.tar.gz' and 'unrar.tar.gz' decompressors
- Test and submit a 7zip decompressor to work with 'cdisplay' (Try to see if '7zDec' works)

Posted by ^thehatsrule^ on Sep. 16 2007,17:04

Quote (stupid_idiot @ Sep. 16 2007,09:34)

re: rar/7z: If yours are newer versions than the one I have previously posted, please request to have them replaced (as I don't think anyone would necessarily require older versions of these applications)

Posted by curaga on Sep. 16 2007,18:55

I have a question: since the unrar binary from Rarlabs is already nicely packaged as a tar.gz, just needing extracting somewhere, isn't it kinda pointless to create an extension out of it?

Posted by ^thehatsrule^ on Sep. 16 2007,21:58

That's because it's not a mydsl extension.

It's similar to in windows, where some offer a self-installer or sometimes just the files in some .zip.
Most would choose the installer, since it could add stuff specific to the system.

Not to mention other benefits, such as a central location, etc.

Posted by stupid_idiot on Sep. 17 2007,10:17

Quote (curaga @ Sep. 16 2007,22:55)

I have a question: since the unrar binary from Rarlabs is already nicely packaged as a tar.gz, just needing extracting somewhere, isn't it kinda pointless to create an extension out of it?

I checked what was on the ftp server.
There's stable 3.5.3, and dev 3.7.5; both need libstdc++6 (DSL only has libstdc++5).
Hey, thanks for the suggestion anyway. I should have checked!

Posted by WDef on Sep. 18 2007,22:31

@stupid_idiot:

Thanks and keep up the good work on the wine uci ...

unfortunately I'm getting some errors with the updated uci on a win app that previously worked well (eg address violations).

Could we perhaps have the previous version back as well for the time being? - I deleted it and no longer have it.

Posted by stupid_idiot on Sep. 19 2007,00:06

Hi WDef:
Okay, I will see what I can do.

Posted by ^thehatsrule^ on Sep. 19 2007,04:56

For software packages that have many regressions or changes per release, it would be ideal to keep all of them.
This could include things like wine, drivers (like video), X... amongst others.

Posted by stupid_idiot on Sep. 19 2007,13:49

WDef:
'wine-0.9.42.uci' has been sent to extensions@damnsmalllinux.org.
If you need it quickly, it is also on rapidshare: < http://rapidshare.com/files/56781953/wine-0.9.42.uci.html >

Posted by stupid_idiot on Sep. 20 2007,14:19

Quote (^thehatsrule^ @ Sep. 16 2007,21:04)

Oh dear.. I read your reply two days ago but I forgot all about it.
I sent in 'p7zip.tar.gz' and 'unrar.tar.gz' just a few hrs ago.
I have sent another email to Robert and told him NOT to put them up.
I am very sorry!

p.s.
(1) mydsl/system/p7zip-4.42.tar.gz is 2.4M.
(I see this is the full 7zip which supports a great range of formats besides just 7z.)
'p7zip.tar.gz' which I submitted is the 'reduced' 7zip - the binary is called '7zr' - it supports only 7z/LZMA/BCJ/BCJ2.
It is small (176K) and is intended for use with the 'cdisplay' script (mydsl/testing/cdisplay.tar.gz) for decompressing .7z archives, so the other formats won't be used at all.

(2) mydsl/system/rar.dsl is 296K ('rar' + 'unrar'); I submitted the 'unrar' binary as 'unrar.tar.gz' (70K).

(3) I think 'unrar.tar.gz' can be abandoned since 'rar.dsl' is only a little bigger. But regarding p7zip - I still wish to submit '7zr', but I don't know what name to use. May I ask you what you think? (BTW, in Debian, '7zr' is called 'p7zip' and the full-featured '7z' is called 'p7zip-full' - maybe we could do this as well?)

Thank you very much, and very sorry for my mistake.

Posted by ^thehatsrule^ on Sep. 20 2007,23:10

Typically I keep the naming convention similar to uci's, that it's in /opt/filename so it becomes filename.extension
What is your file tree structure?

Although it would be fine to put both in since they have different filenames, I agree that something more explicit should be used. However, because of the above, I'm not sure how to proceed.

Since yours is only unrar and its a .tar.gz, I think you should still submit that one.

Posted by stupid_idiot on Sep. 21 2007,07:25

1. '7zr' is a standalone, so the file tree is really simple:

Code Sample

tar -zcvf p7zip.tar.gz --numeric-owner /opt/bin/7zr /opt/bin/p7zip

'/opt/bin/p7zip' is a wrapper script that emulates gzip.
e.g. 'p7zip -d foo.tar.7z' (This will run '7zr' to decompress the file.)

2. Regarding the naming: Perhaps 'p7zip' and 'p7zip-full' can make more sense if they are put together in 'mydsl/system/'. When 'p7zip' is seen alone, people have no idea that it is actually a limited version. As for 'p7zip-lite', it seems wrong - '7zr' has core .7z support after all, so it is not a 'reduced-functionality' version as seems to be implied by '-lite'. So, I don't have any better idea than what Debian is using - 'p7zip' & 'p7zip-full'.

3. About 'unrar' - thanks very much. I will resubmit it then.

Posted by ^thehatsrule^ on Sep. 21 2007,15:32

Heh, instead of "lite" I was thinking of terms more like "unrar," like using "7zr"

This brings me to ask a general question about .uci/.tar.gz extensions, regarding the use of /opt/bin: afaik they were added to PATH for the use of symlinks. Should this be kept for symlinks only? What should the standard be?

If not only for symlinks, this rules over the traditional /opt/packagename structure... if this is the case, then probably renaming the current extension without modifying its contents should be fine then.

EDIT: this seems to be getting long and a bit off this thread. If there are no simple answers and it gets any longer I think it should be moved to another.

Posted by stupid_idiot on Sep. 21 2007,22:04

I also like '7zr.tar.gz', so I will resubmit with this name.
Thanks very much.

Posted by andrewb on Sep. 24 2007,04:12

Not really a September extensions issue, & only minor, but there are 2 versions of XFree86-devel.dsl in the repository - one in testing and one in system. The listed extension sizes are different (4.3M & 3.8M), both are listed as version 4.3.0.

Posted by curaga on Sep. 24 2007,07:01

@andrewb: check the .info files, the one in testing has a clobbering dir fixed

Posted by stupid_idiot on Sep. 24 2007,17:15

FTW:
- Update 'mplayer.uci' to latest svn. Last update was 1 mth ago.

Posted by curaga on Sep. 24 2007,17:41

Um, how did the inclusion of extensions from testing to the usual categories go? There are some that have been there over a year..

Posted by roberts on Sep. 24 2007,21:40

I believe John is working on a new search capability for the repositories. I am not sure what exactly is planned. So until then, the testing area keeps growing. I think we have out grown the original categories and need a much better way to search and find extensions. I know I will be looking forward to the overhaul.

Posted by roberts on Sep. 25 2007,05:13

New extensions now posted:

Thanks to Juanito for:
cifs.o posted in the modules section. And in the testing area:
samba-3.uci
hplip.uci

Thanks to J.S. for:
curl.tar.gz
cdisplay.tar.gz
7zt.tar.gz
unrar.tar.gz

Thanks to yangmusa for:
aspell.dsl

Thanks to Curaga for:
Glxprogs.info updated.

Posted by stupid_idiot on Sep. 25 2007,10:21

Excuse me, Robert:
Have you received the following extensions?
- unace.tar.gz
- wine-0.9.42.uci
- wine-0.9.4x.uci (v0.9.45)

Thanks.

Posted by roberts on Sep. 26 2007,05:38

unace.tar.gz now posted!

wine-0.9.4x failed md5sum check, email was sent indicating such.
Wouldn't wine-0.9.4x trump v0.9.42?

Posted by stupid_idiot on Sep. 26 2007,09:27

It was because WDef requested to have the previous version up:

Quote (WDef @ Sep. 19 2007,02:31)

@stupid_idiot:
Thanks and keep up the good work on the wine uci ...
unfortunately I'm getting some errors with the updated uci on a win app that previously worked well (eg address violations).
Could we perhaps have the previous version back as well for the time being? - I deleted it and no longer have it.

Also: I will resend 'wine-0.9.4x.uci'.
Thanks!

Posted by ^thehatsrule^ on Sep. 26 2007,15:07

Quote (roberts @ Sep. 26 2007,01:38)

Wouldn't wine-0.9.4x trump v0.9.42?

Also, please consider my suggestion (from earlier post):

Quote

For software packages that have many regressions or changes per release, it would be ideal to keep all of them.
This could include things like wine, drivers (like video), X... amongst others.

Also, can you answer this roberts? (should probably ask this in the extension dev thread, but asking here just in case someone is following in this one)

Quote

regarding the use of /opt/bin: afaik they were added to PATH for the use of symlinks. Should this be kept for symlinks only? What should the standard be?

Posted by roberts on Sep. 26 2007,23:25

Prefer symlinks, as adding actual binaries would consume ramdisk, especailly true for uci.

Posted by roberts on Sep. 26 2007,23:26

Posted wine-0.9.4x.uci and sopcaster.uci

Thanks to J.S. and Humpty.

Posted by stupid_idiot on Sep. 28 2007,08:05

Hi Roberts:
Would like to volunteer to reduce size on apps in mydsl/testing.
What I want to do is:
1. D/L extensions
2. Unpack and look for documentation, locale data, unstripped binaries & libraries, ..
3. Maybe 'upx --best' on the bigger binaries?
4. Run 'advdef -z4' on tarball-type extensions
5. Re-submit just the extension file + .md5.txt (.info file unchanged). [probably should submit in bulk?]
The reason I suggest this is because you might be busy with other things, yes?
Is this okay? Will be happy to help out.
Or, is this impractical because of [reasons]?
Thanks.

Posted by curaga on Sep. 28 2007,12:33

The upx would be impractical: DSL is targeted to low machines, and upx must decompress the whole executable into memory!
Think 16mb without swap and OO.o.. crash or crash?

I don't think there's any need to remove docs, as the ones included are included for a reason (like my grub doc, or the XF86config examples)

In my opinion you should only remove the .po files, strip, and repack with advdef.

Posted by stupid_idiot on Sep. 28 2007,13:22

However, the upx website says this:
"Your executables suffer no memory overhead or other drawbacks because of in-place decompression."
- < http://upx.sourceforge.net/#abstract >

This is my (very unsophisticated) understanding of binary execution under Linux:
"Linux binary files are laid out in a way that pages on disk can be mapped into memory. Only the pages that are accessed ever hit memory." - < http://mysqldump.azundris.com/archives/62-Notes-on-VM.html >
Perhaps upx works this way also? That would justify the authors' claim of "no memory overhead".

If the above interpretation is correct, then the main determinant of upx performance would be cpu speed, when running the NRV decompression algorithm to load pages into memory. Judging by how the authors tout NRV as very fast, then a upx'ed binary probably has performance very close to a binary running from uci (since cloop also uses on-the-fly decompression).
If the following is to be believed -
"very fast decompression: ~10 MB/sec on an ancient Pentium 133, ~200 MB/sec on an Athlon XP 2000+." - < http://upx.sourceforge.net/#overview >
- then the speed difference between upx and cloop seems only academic.

Posted by curaga on Sep. 28 2007,14:53

Oh. The method for decompressing in memory is only used for scripts and a.out type apps. Sorry, didn't check..

There is still one major drawback with using upx: you cannot see the dependencies without a patched file.. and there is no patch for the busybox version

Posted by ^thehatsrule^ on Sep. 28 2007,15:10

For 3: I believe using upx was decided against in general (i.e. for base), but for extensions I'm guessing it's up to the extension maker. How big is "bigger"?

EDIT: wow I did not see page 9 at all... I think the main reason was that performance was favoured in place of size.

Posted by jls legalize on Sep. 28 2007,15:27

I've made < avidemux > mydsl optional extension.

legalize cannabis, coke, ..

Posted by roberts on Sep. 28 2007,15:44

upx and advdef have both been discusses before. If DSL were only offered a traditional hard drive install, then a smaller download size with a 'single expense' to uncompress several layers of compression would be acceptable.

However, DSL is designed to be a nomadic live CD, or frugally 'installed' system. As such the initial savings in download time is lost if it means upon every boot one must again have the 'expense' to uncompress several layers of compression. It would mean slower startup times for each extension and much slower boot up times for systems where many extensions are auto loaded upon boot. Plus the extra burden on the less powerful CPUs that DSL still fully supports.

Given the design philosply of DSL I cannot see a benefit of layering compressions.

Posted by stupid_idiot on Sep. 28 2007,15:46

Quote (curaga @ Sep. 28 2007,18:53)

There is still one major drawback with using upx: you cannot see the dependencies without a patched file.. and there is no patch for the busybox version

Yes. But on running, the program will show "Cannot find libxyz.so.x. ...".
And then it should be easy to find what is missing. Also, let's say the user does not know what "Cannot find libxyz.so.x. ..." means. In this case, even if he could do 'ldd xyz', it won't be of use to him..

But, let's say we have a worst-case scenario where a large number of libraries go missing, and the app won't start.
There are 2 possibilities:
1. The missing library is an important system library. In this case, many other programs that depend on this library will also fail.
2. The missing library is a minor library, possibly used only by this specific app. In this situation:
(a) The .info file for the extension should describe what other extension(s) is needed. (This assumes the user has read the .info file before downloading. Also, this assumes the .info file is clear and easy to understand.)
(b) In the case of a .dsl or .tar.gz, where installed files may be accidentally deleted, we can reinstall by reloading the .dsl/.tar.gz.
© In the case of a .uci, the $PREFIX is read-only, so libraries shouldn't go missing.

Posted by ^thehatsrule^ on Sep. 28 2007,16:31

advdef shouldn't have any difference on the end user. It is only during (re)compression where it takes more time. So that is up to the extension maker as it provides an advantage only -- in the size. However, upx is a different case altogether and I would be against implementing it due to all the disadvantages (and would not be a viable option in every extension anyways, regardless of implementation).

Posted by stupid_idiot on Sep. 28 2007,16:43

Robert:
It seems to me that upx operates in much the same manner as a cloop-mounted uci. Assuming (for the sake of argument) that their speeds and memory usage are similar, I do not see an appreciable difference between the two. If so, why is uci acceptable and not upx?

Posted by roberts on Sep. 29 2007,02:54

I don't force everyone to use UCI. Typically we have extensions in many flavors. Typically the user has a choice of extension flavor depending on hardware capabilities.

If I understand this correctly, you would be upx compressing all the binaries and then again, the tarred package with gzip or advdef. That double (second) compressing is not going to yield much.

It would be like me gzipping the ucis or for that matter gzipping the isos. Not much advantage for the effort during creation and during unpacking.

I still think this approach is best for a traditional hard drive installed system and providing smaller downloads.

Lets try this...

Make one of a significant size, i.e., not a trivial extension, and one that takes argument(s).

I will post it in testing and will test and compare on a 32MB 90Mhz machine.

Hopefully we can get one of our Libertto users to also test and report back and anyone else with a low end machine.

No promises that this approach will be implemented. Just a test and comparision of actual results.

Posted by stupid_idiot on Sep. 29 2007,04:20

Thanks Robert. I will try to do that.
It will take a while to prepare one for testing.
p.s.
qemu with -kernel-kqemu has made it very easy to do testing with DSL.

Posted by stupid_idiot on Oct. 04 2007,07:23

Hello Robert:
- There seems to be a duplicate of 'wine-0.9.4x.uci' on this page:
< http://distro.ibiblio.org/pub....testing >
- 'wine-0.9.42.uci' is not up yet; should I re-send?
Thanks!

Posted by roberts on Oct. 04 2007,15:36

Blank lines in the comments section will cause that apparent duplication. Fixed. There was also a missing ":" on the Current tag for sopcaster that caused the fields to get messed up on that as well. Fixed.

Yes, please resend the (older?) version of wine.

Posted by jpeters on Oct. 08 2007,20:01

I tried out wine-0.9.42.uci with FundManager. It initially loaded, but couldn't see a subdirectory when I attempted to load another portfolio.
Wine-20050524.uci works.. I'm not sure if this is related, but after unmounting it, I had to reboot because other apps wouldn't load.

Edit: wine-0.9.28_with_opengl.unc also works.

Posted by jpeters on Oct. 21 2007,03:52

Quote (jpeters @ Oct. 08 2007,16:01)

wine-0.9.4x.uci solved the problem; also connects to broker sites for updates. Wine_0.9.28_with_opengl.unc fails. (Wine-20050524.uci can also update).

Posted by stupid_idiot on Oct. 21 2007,14:12

Hi Robert,
Could you please remove 'python2.5.uci'? ('python-2.5.uci' replaces it.)
Thanks!