Forum: The Testing Area
Topic: September Extensions
started by: roberts
Posted by roberts on Sep. 01 2007,15:42xorg72setup.tar.gz is now posted in testing.
Thanks goes to ^thehatsrule^
Posted by roberts on Sep. 05 2007,21:51Updates to hplip extension:
And a new info file too.
Thanks goes to Juanito.
Posted by Juanito on Sep. 07 2007,17:51I'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:37In 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.
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:18New or updated extensions now posted!
Thanks to J.S. for:
Thanks to Juanito for:
Thanks to lucky13 for:
Posted by roberts on Sep. 11 2007,19:23Juanito wrote:
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:23Fair, 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.
Posted by stupid_idiot on Sep. 12 2007,08:35Hey - that would dilute the spirit of volunteerism.
(On a totally unrelated note)
Roberts, did you receive my email with 'mplayer.uci' and a few other extensions, about a week ago?
Posted by curaga on Sep. 12 2007,16:53I 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
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
Posted by stupid_idiot on Sep. 13 2007,05:32Hi Roberts:
I've forwarded my original email to firstname.lastname@example.org. Could you please check for it?
Posted by roberts on Sep. 16 2007,05:04codecs-qtx.uci
Now posted. Thanks to J.S.
Posted by stupid_idiot on Sep. 16 2007,13:34Plan 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
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:55I 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:58That'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
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:06Hi WDef:
Okay, I will see what I can do.
Posted by ^thehatsrule^ on Sep. 19 2007,04:56For 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:49WDef:
'wine-0.9.42.uci' has been sent to email@example.com.
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
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!
(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:10Typically 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:251. '7zr' is a standalone, so the file tree is really simple:
'/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:32Heh, 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:04I also like '7zr.tar.gz', so I will resubmit with this name.
Thanks very much.
Posted by andrewb on Sep. 24 2007,04:12Not 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:15FTW:
- Update 'mplayer.uci' to latest svn. Last update was 1 mth ago.
Posted by curaga on Sep. 24 2007,17:41Um, 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:40I 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:13New extensions now posted:
Thanks to Juanito for:
cifs.o posted in the modules section. And in the testing area:
Thanks to J.S. for:
Thanks to yangmusa for:
Thanks to Curaga for:
Posted by stupid_idiot on Sep. 25 2007,10:21Excuse me, Robert:
Have you received the following extensions?
- wine-0.9.4x.uci (v0.9.45)
Posted by roberts on Sep. 26 2007,05:38unace.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:27It was because WDef requested to have the previous version up:
Also: I will resend 'wine-0.9.4x.uci'.
Posted by ^thehatsrule^ on Sep. 26 2007,15:07
Also, please consider my suggestion (from earlier post):
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)
Posted by roberts on Sep. 26 2007,23:25Prefer symlinks, as adding actual binaries would consume ramdisk, especailly true for uci.
Posted by roberts on Sep. 26 2007,23:26Posted wine-0.9.4x.uci and sopcaster.uci
Thanks to J.S. and Humpty.
Posted by stupid_idiot on Sep. 28 2007,08:05Hi 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]?
Posted by curaga on Sep. 28 2007,12:33The 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:22However, 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:53Oh. 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:10For 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:27I've made < avidemux > mydsl optional extension.
legalize cannabis, coke, ..
Posted by roberts on Sep. 28 2007,15:44upx 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
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:31advdef 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:43Robert:
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:54I 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:20Thanks Robert. I will try to do that.
It will take a while to prepare one for testing.
qemu with -kernel-kqemu has made it very easy to do testing with DSL.
Posted by stupid_idiot on Oct. 04 2007,07:23Hello 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?
Posted by roberts on Oct. 04 2007,15:36Blank 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:01I 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
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:12Hi Robert,
Could you please remove 'python2.5.uci'? ('python-2.5.uci' replaces it.)