Request for .ucis
Forum: myDSL Extensions (deprecated)
Topic: Request for .ucis
started by: reidar
Posted by reidar on June 02 2005,09:38
I have been trying most of the .ucis with my frugal installed system, and I am becoming more and more impressed! Some time ago I learned enough about .dsls to create a few with cbaggers brilliant script, but using frugal install on an older laptop has made me understand the power of .ucis. Now, I have been reading about how to create a .uci extension in the docs and also in the forum, but I feel that "I am not there yet" (i.e. I don't really understand it all yet...), so here is a modest request for a couple of apps that I believe should be made into .ucis:- Abiword (a good word-processor is vital, and OpenOffice.uci can be too big sometimes...)
- GIMP (a really good app, which is virtually impossible to use on low-ram systems as a .dsl)
- Scribus (would be really nice to have, and I suppose it would be a big app, so .uci would be preferable, I think)
Now, I don't really know if it is possible/easy/hard to create .ucis from these apps, but seeing what kind of uci-extensions have been made lately, I was encouraged to ask. (If someone would rather give me another explanation on how to create these .ucis myself, please do!)
-r
Posted by meo on June 02 2005,10:55
Hi reidar!I fully agree with you especially whan it comes to gimp. I have been trying just like you to get the hang of HOWTO make uci files but i haven't reached there yet. So hopefully it will come or we get to the point when we can make our own uci files.
Have fun,
meo
Posted by Guest on June 03 2005,16:13
At which point in the procedure did you have problems?Most of the time, the uci extensions can be made from recompiling the package from source. This allows you to specify the destination of the compile output to be at /opt instead of /usr or /usr/local. Implication: you have to have the compilers and development libraries. Unfortunately (and logically), they were stripped from DSL and the gcc1.dsl extension is not enough for most instances. But you can compile stuff using Knoppix 3.4 (on which DSL was based) and create the uci with it, then test the uci in DSL. If the package you want to compile requires fortran (g77) which Knoppix does not have, you can try using Quantian 0.5.9.2 cd (not the dvd).
Reidar, try it and make a lout.uci so that you can update the dsl version you submitted. I was able to do it so I am quite sure you can. I will not submit my version.
Posted by reidar on June 06 2005,05:37
I wasn't aware of the fact that you had to/could perform the compilation in Knoppix 3.4. This is interesting news! I will go ahead and try creating a lout.uci. That will give me an opportunity of finally trying to compile a package from source, which I have (shame on me!) actually never tried before ...Thanks!
-r
Posted by reidar on June 06 2005,07:31
I tried to make a lout.uci in Knoppix 3.4, but I didn't succeed. What I did was the following:- booted Knoppix 3.4
- downloaded lout.tar.gz (source of the latest lout package)
- created a /home/knoppix/work directory, where I put lout.tar.gz
- unzipped it: tar -zxvf lout.tar.gz
- cd lout-xxx (the directory created from last point)
- created a /mnt/hda3/opt/lout on my hda3, since I wasn't allowed to create a /opt/lout from the cd, which I wanted.
- read the 'makefile' instructions and followed them (set BINDIR=/mnt/hda3/opt/lout)
- make prg2lout (worked out fine)
- make lout (also seemed to work out fine)
- make install (did not work out, since it wanted to use BINDIR=/home/jeff/lout or something. This was the bindir mentioned in 'makefile', and has never been a directory on my computer...)
- created a /home/jeff/lout directory, ran 'make install' again
- mv * from /home/jeff/lout to /mnt/hda3/opt/lout
- cd /mnt/hda3/opt/
- created the .uci by the following command (from the docs); 'mkisofs -R -hide-rr lout | create_compressed_fs - 65536 > /home/user/lout.uci' (user being replaced by my username)
Now, this finally worked out and I had gotten a lout.uci. I then booted dsl from cd to try it out, but it didn't work. I figured out that this was due to the fact that I had compiled lout with BINDIR=/home/jeff/lout instead of /opt/lout (which I really wanted, but was unable to - see above). So, I basically got a useless lout.uci that doesn't work... :-(
Any ideas on what I did wrong, or how I can make it right? Would appreciate any feedback on this! (And bear in mind that this is my first attempt at compiling anything ... ever)
-r
Posted by mikshaw on June 06 2005,14:52
Not sure why you were not allowed to create a directory in /opt, but you shouldn't need to do that step anyway....usually the installation process creates that directory automatically. If you need root access in Knoppix, this will be done during install...you should su to root for the 'make install' command.Does your source package contain a 'configure' script? If so you can specify a target directory with "configure --prefix=/a/path". I'm guessing configure wasn't included, though, since you mentioned only 'make'.
Using a /mnt/something for installation probably isn't a good idea, since the compiled program will likely be looking there...if you move your program it might end up with missing files. If you don't have the space in /opt, you can create a symlink in /opt to /mnt/something. Again, I'm not sure why you were not able to create a directory in /opt, but it may just be that you need root power.
Posted by roberts on June 06 2005,15:50
If the source comes with a configure program usually typing ./configure --help will display all setable options. Many times there will be multiple options for alternate pathing.
Posted by cbagger01 on June 06 2005,16:58
Yes, try this:sudo ln -s /mnt/hda3/opt /opt
and then point your compiler at /opt/lout and see if it works.
Posted by Guest on June 06 2005,18:25
Reidar,cbagger01 is right. You have to at least trick the process into believing that it is going to install to /opt/lout, even though you are physically installing it to /mnt/hda1/opt/lout. Therefore, the BINDIR has to be /opt/lout and the symlink has to be created.
Mikshaw and Roberts, unfortunately the lout package doesn't have ./configure so reidar cannot do as you suggested. But if reidar decides to compile the sc.dsl and pspp.dsl (both GNU) as uci, then your suggestions will have to be followed.
More work ahead for you, reidar. But don't flood ke4nt1 with your enthusiasm
Posted by clivesay on June 06 2005,19:32
Who is this mysterious 'Unregistered Guest'? who has been most helpful recently in the forums 
Zorro? Lone Ranger? Batman?
Posted by reidar on June 07 2005,04:55
I vote for Batman! :-)Thanks to everyone for your advice! I am always amazed about the level of knowledge within this community. Really a great place for learning! I will try this out again, bearing your advices in mind. Thanks a lot everyone!!!
-r
Posted by reidar on June 10 2005,04:59
Oh, happy day!!! I have finally managed to create my first .uci extension! This is great. I must admit that it wasn't the lout-package, which I tried to compile the other day, but rather the Norwegian translation of Openoffice 2 (the beta version), including extra fonts. The only problem was that I screwed up the menu entrance somewhat, forgetting that the initial name of the app (/opt/openoffice1.9.82) was different from the name I gave it (openoffice2). This caused the fluxbox menu to collapse actually, but the application worked like charm. I will only have to clean up the user.tar.gz as far as the menu entrance is concerned! This is great!
-r
Posted by reidar on June 10 2005,08:46
I am not really fond of endlessly following up on my own posts, but I cannot help it! So please bear with me I have now made a new openoffice2.uci (from the Norwegian translation of Openoffice2 - beta version), and now I managed to get the mydsl-menu entrance right also. So it works beautifully. Great! Only thing I don't get is that the first time I launch Writer (or any of the other OOo-apps) after I mounted the .uci it takes quite a while to start up. After that, they launch in less than 5 secs (on my office computer that is).
I have also made a successful softmaker.uci, containing textmaker and planmaker (plus a few additional fonts). I am not sure if I will submit any of these though, since the Norwegian version of OOo2 is only interesting to a couple of you, and textmaker/planmaker is commercial software, so I am probably not allowed to... But I would recommend you all to try them out! There are free versions available for evaluation, and they work fine. It is easy to create your own .dsl/.uci from them, and they work beautifully in DSL! Even on my old laptop with 56MB RAM textmaker starts almost before I have finished clicking the icon!!! Seriously!
I see that SAM (the Linux live cd) and also Puppy include free versions of textmaker (Puppy only through their so-called PupGet system) and planmaker. Perhaps DSL could get a similar deal with the Softmaker team?
-r
Posted by Guest on June 10 2005,13:34
Two things about OpenOffice that makes it take a while to start initially and less than 5 seconds afterwards --- disk buffers and the user settings folder.Disk buffering is used by the operating system to kind-of predict what files you access from the hard disk or compressed image devices (like the uci) are used often. A copy of these will reside in the memory as long as the memory is free.
If you notice that the memory monitor has both a blue and gray (and sometimes red) indicator bar, the buffer is the gray bar. The memory represented by the gray bar includes the files in the ramdisk (including /opt, /var, and /home) and the disk buffers. Although the contents of the buffers can be displaced when the memory is needed, the contents of the ramdisk can't be removed as readily unless swap space is available and the files are not in use.
Once Openoffice is run for the first time, it will look for some files containing the user settings. If there is none, it will be created. The time consumed at this stage can be minimized by creating the user settings files and including them in the user.tar.gz. Refer to the Openoffice uci created by Roberts for example.
Posted by davide on June 10 2005,13:51
Reidar, just to know...what laptop are you using Ooo2.uci ? it sounds like you're using Ooo on a 56Mega ram system and that sounds cool. Apart of the first start, which always takes time, does it work fine? do uci work fine on older laptop also for abiword and gimp? (as far as you may know)?
congrats for you learning curve...you're fast!
Posted by reidar on June 10 2005,14:11
I did create a user.tar.gz, very much like the one in Robert's openoffice.uci. But I realise now that I might have done it somewhat wrong. I will check it out. I did create a user.tar.gz where I incorporated the .openoffice1.9.82/ folder initially created by the app. I realised know that my changing the name of the program (and thereby also the /opt/openoffice-folder) from openoffice1.9.82 to openoffice2 might cause the hidden folder in /home/dsl to be renamed. So, while my user.tar.gz contained a /home/dsl/.openoffice1.9.82 folder, the app will probably try and create a /home/dsl/.openoffice2 folder? This could be the reason why it takes somewhat more time to boot the first time... I will check this out!Davide: I do use openoffice.uci on an older laptop, 56MB RAM. It is a Compac Presario 1210 or something like that. It works but it is slow. On my office-computer though, Dell Optiplex 270 with 512 MB RAM, it rocks!!!
I don't know about abiword and gimp ucis. I haven't seen any yet, but I hope there will be made some! The ordinary abiword.dsl and gimp.dsl doesn't work for me on the old laptop (I have a frugal install and the larger dsls eat up too much RAM).
And thanks for the congrats
I am not sure if I am really a fast learner, but I love it that you can learn so many new things while using DSL!!!
-r
Posted by reidar on June 13 2005,06:57
Just for the record: the somewhat long initial start-time for my openoffice2.uci had nothing to do with my giving the directory in user.tar.gz a different name from the app. I tried changing it to /home/dsl/.openoffice2 in user.tar.gz, just to see that two directories were made in /home/dsl when the app was first booted, one /home/dsl/.openoffice2 and one /home/dsl/.openoffice.org1.9.82 (which was the initial name of the app). So my previous attempt (closely following the instructions from the docs!) was right. The somewhat longer time it takes for the app to start the first time must have a different reason. I guess it is like the mysterious Mr. 'Guest' said earlier in this thread:| Quote |
| Disk buffering is used by the operating system to kind-of predict what files you access from the hard disk or compressed image devices (like the uci) are used often. A copy of these will reside in the memory as long as the memory is free. |
-r