Lunar Linux - User contributions [en]

Module Submission

2007-03-10T20:04:07Z

Sofar: /* So what do you need to be able to submit a module? */

===Submitting modules to the official Moonbase===

====Why would I want to?====

The official [[Moonbase]] is maintained and updated by the [[Lunar Linux]] developers.
But what if there isn't a module in the [[Moonbase]] for the package that you want,
or it is not the latest version, or it is out-of-date in some other way?

Well obviously you can report the problem via
the [http://bugs.lunar-linux.org/view_all_bug_page.php Bug Tracker],
the [http://forums.lunar-linux.org/ Forums],
the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List], or discuss it on
the [irc://irc.freenode.net/lunar #Lunar] IRC channel on [http://freenode.net/ Freenode.net]
and hope that someone can help you.

Or you can scratch your itch the open source way and create or update the module yourself using the information in
the articles:
[[Module Basics|A basic module outline]] and
[[Module Writing|Writing Lunar-Linux Modules]].
''Remember to work in the [[zlocal]] section so that your updates are not lost the next time you download a new Moonbase.''

And then what?
Maybe other people could benefit from your module.
Maybe other people could improve your module.
So why not submit it to the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List]
so that the others can see it and the Lunar developers can decide whether to include it in the [[Moonbase]]?
Even if they don't, your module will still be available to interested parties via the mailing list archive.

====So what do you need to be able to submit a module?====

* '''You need to be subscribed to the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List].''' Why not do it now anyway?

* '''You need to have a working out-going mail connection.''' Maybe you haven't yet got or don't want to have a full mail installation on your system. Then you will need to install a minimal out-going mail only system. Download the [http://modules.lunar-linux.org/index.php?option=module&module=esmtp esmtp] module from the [[Moonbase]] and configure the ''/etc/esmtprc'' or ''$HOME/.esmtprc'' file. That's all there is to it.

* Simply run '''lvu submit myModule'''. You will see a submission template in the editor of your choice. Fill in the blanks: email address, some module details, and some explanatory text about your submission. Are you happy with the BUILD file? What options have you tackled? How much testing have you done? Write the template and submit. It's as easy as that.

* '''Remember to watch the mailing list for feedback.''' It might show up as a new module in the Weekly Overview without further comment. You might not hear anything more because the developers are all busy with mainstream infrastructure and modules, but at least you have contributed and your contribution is available in the archives for other interested users.

* '''If you don't have sendmail or esmtp installed''', you can still send updates as patches. Creating a patch is as easy as '''lvu diff myModule > myModule.patch'''. Send the patch file as an attachment to the mailinglist and it will be picked up as a normal submission.

Lunar Linux:FAQ

2006-11-14T22:57:28Z

Sofar: /* What are safe optimizations? */

These are the '''F'''requently '''A'''sked '''Q'''uestions for Lunar Linux. You have a question about Lunar? You might get your answer below.<br /><br />

__TOC__

==General==

===What is Lunar Linux?===
What exactly is Lunar Linux?

'''Answer:'''
* Please read [[Lunar Linux:About|About Lunar Linux]].

==Optimizations==

===How do I set optimizations?===
How do I set these optimizations for my machine?

'''Answer:'''

Run <code>lunar optimize</code>. You'll be taken through an interactive menu that explains all the options. Remember to optimize safely.

===What are safe optimizations?===
What are the recomended safe optimizations for [[Lunar Linux]]?

'''Answer:'''

The default sure fire optimizations that are recommended are:

* '''C'''
** <code>-pipe</code>
* '''C++'''
** <code>-pipe</code>
* '''CPU Architecture'''
** You should pick the correct architecture for your own system (defaults to x86 for most people).
* '''Basic Optimzations'''
** Faster (-O2, the default) or Fastest (Note that fastest doesn't work on all systems, i.e. k6).
* '''CPU'''
** This, of course, should be set to your own cpu, or the cpu of the machine you plan to run this install on. If you want to be able to run this install on many machines, you should be safe with I686.
* '''Speed Optimizations'''
** If you want to be 100% sure that there won't be optimization problems you shouldn't select any of these.
* '''Extra features'''
** It is not recommended to use any of these optimizations, even for modules known to be able to handle them, since they cause many apps to break.
* '''Floating Point Math'''
** None. If your architecture is x86 and you don't own a 386SX and 486SX, it's safe to select x387.
* '''Linker Options'''
** Strip.
* '''Addon Program Support'''
** CCache. Make sure to install it first.

These settings should work for almost everyone, and there is a lot room for pushing these optimizations more, at the risk of problems with some applications. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations may cause problems?===
What optimizations are known to cause problems in some setups?

'''Answer:'''

Some optimizations that are known to cause problems on x86 with many applications, and even a entire system:

* <code>-funroll-loops</code>
* <code>-fstrict-aliasing</code>
* <code>-ffast-math</code>
* <code>-ffloat-store</code>

These are sorted from the least unstable to most unstable. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations can give some speed without issues?===
What optimizations can I use to gain some speed but without major risks?

'''Answer:'''

Start with the basic optimizations in [[Lunar Linux:FAQ#What_are_safe_optimizations.3F|FAQ #2.2]] and change the Basic Optimizations to Faster or Fastest if you know that gcc will generate correct code for that cpu. -O2 obviously takes more compile time than -O1, and -O3 takes the most time to compile. Then select the cpu you will run it on. Some of the speed optimizations that should be decent and shouldn't cause too many problems, if any, are: -fomit-frame-pointer. A safe bet for floating point math on a x86 would be x387, if you know your cpu has a floating point unit. Check <code>cat /proc/cpuinfo</code> to see if your cpu supports SSE or SSE2. If your cpu does have sse or sse2 then you can also add that to the math optimizations.

Your results may vary. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations should I avoid?===
What optimizations should I stay away from?

'''Answer:'''

All the ones listed in the [[Lunar Linux:FAQ#What_optimizations_may_cause_problems.3F|FAQ #2.3]] plus:
* <code>-fprofile-arcs</code>
* <code>-fbranching-probabilities</code>

Please read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it. The Lunar developers will not respond to bug reports of broken compiles by users with risky optimizations.

==Installing modules==

===Can I compile several modules at once?===
Is it possible to install multiple modules at the same time without breaking things?

'''Answer:'''

Yes, Lunar even promotes it. However doing so will cause installs compile slower of course. Lunar will not install core system modules like gcc and glibc while something else is installing and will wait until the rest is finished. Also, you cannot install applications while those major modules are installing, they will wait their turn until it's safe and continue to install them automatically.

===error : C compiler cannot create executables===
What does this error mean and how can I fix it?
* <code>C compiler cannot create executables</code>

'''Answer:'''

Read the next topic - this is basically the same problem: There are kernel headers missing that are vital to compilation. You will have to restore them. Below is explained how to do that.

===configure: error: C preprocessor "/lib/cpp" fails sanity check===
What does this error mean and how can I fix it?
* <code>configure: error: C preprocessor "/lib/cpp" fails sanity check</code>

'''Answer:'''

This is an include file problem. Sometimes ''/usr/include/gnu/stubs.h'' is missing, this can be found in the glibc source tarball. Most of the time the following applies:

Your kernel headers are missing from <code>/usr/include</code>. This means the C PreProcessor cannot verify that it has the proper cached copies of those vital header files. You need to install the proper ones manually. Here's how:

lin kernel-headers-2.4

This might work for you! (Use the 2.6 version if needed of course)

Otherwise:

mkdir -p /usr/include/{linux,asm}

to create the two target dirs, if needed. Then execute:

cp -av /usr/src/linux/include/linux /usr/include/
cp -av /usr/src/linux/include/asm/* /usr/include/asm/

to copy the files manually. Be warned that the second command has to be done this way since <code>/usr/src/linux/include/asm</code> is a softlink to your arch asm header files, asm points to asm-i386, on x86 machines. So if, on the other hand, you had copied

cp -av /usr/src/linux/include/asm /usr/include/

you would then get a softlink to nowhere under <code>/usr/include/</code>.

Last, you can always try to unpack the kernel tarball you have into <code>/usr/src/linux</code> and manaully link or copy the headers over yourself.

===Can I add more window managers to gdm?===
How do I add other window managers to the sessions list on gdm?

'''Answer:'''

Copy the desktop startup files to <code>/etc/X11/dm/Sessions/</code>. That works with gdm. For kdm you will have to copy them to <code>$KDE_PREFIX/share/apps/kdm/sessions</code>.

===How do I get Flash to work in Mozilla or Firefox?===
How do I get Flash to work in Mozilla or Firefox?

'''Answer:'''

If you are using Mozilla or Firefox, then you can simply do a <code>lin flash-plugin</code> and that will download and install the Macromedia Flash plugin that works with a gtk+ based mozilla through the old abi wrappers.

The flash plugin does ''not'' work with Galeon. The Galeon developers have declined to provide the "old" abi wrappers needed for the plugin to work.

===How do I install Java?===
How do I get Java for my Lunar box?

'''Answer:'''

You will have to download the Java source code from Sun yourself and you have to "click" to agree on their license. You have to compile it yourself too. We don't have a Sun Java module as we currently have no way to automate the "click" to agree to the Sun Java license. See this URL for some handy info:

http://www.linuxfromscratch.org/~tushar/hints/javafromscratch.txt

There is a j2sdk module in moonbase which is the Blackdown port of Sun's Java Virtual Machine.

==Lunar core tools==

===How can I recompile my module with new options?===
How do I force lunar to recompile my modules with different options?

'''Answer:'''

Try:

lin -r ''MODULE''

The -r switch will allow you to select new configuration and dependencies for modules.

===How can I make modules recompile instead of resurrecting?===
How do I tell lunar to recompile my application instead of resurrecting it?

'''Answer:'''

Try doing:

lin -c ''MODULE''

The -c option means tells <code>lin</code> to compile this module even if there is an install cache copy available in <code>/var/cache/lunar</code>.

===My moonbase is gone and I can't install anything.===
How do I fix problems with my moonbase when it's missing or damaged?

'''Answer:'''

Simple solution to this is just running:

lin moonbase

This will download the latest moonbase from the internet, and restore it to working order.

===What is a module?===
What is a [[module]] and what does it do??

'''Answer:'''

A [[module]] is a set of files that tell the core tools the following:

* What name, version, and other properties a package has
* Where to download all needed source files
* What other modules are required, or conflict with this one
* How to unpack the source files, how to patch
* How to configure the code
* How to compile
* How to install everything
* What else to do with it

The [[module]] is coded in a set of files in a directory structure, and scripted in bash.

===What is the Moonbase?===
What is that thing you call [[Moonbase]]?

'''Answer:'''

The [[Moonbase]] is a database with [[modules]]. In this database there are description of packages that tell the core tools where to download, how to compile, and how install a [[module]]. You can consider this the lunar equivalent of portage, grimoire, ports, etc.

===What is theedge?===
What is theedge?

'''Answer:'''

[[theedge]] is the same as lunar, and also known as the core code. Theedge is just another version of lunar. These two pieces of code install your packages, but they do not contain package descriptions. Those are defined in moonbase.

[[Theedge]] is a development version of [[lunar]]. Often there are much more features in theedge, and bugs are fixed quicker as well. However, if you do not like all this tweaking on your system, we advice you to use the stable lunar core tools instead on your system.

You can install [[theedge]] by issuing:

lin theedge

Theedge is automatically updated if you do a <code>lunar renew</code> or <code>lunar update</code>.

==Lunar-Linux Installation==

===So how should I partition my disk?===
I'm setting up lunar from scratch, but how should I partition my disk for a server or desktop system?

'''Answer:'''

Server systems have very different demands than desktops. It's all about flexibility. First desktops:

''desktops'' commonly have one hard disk. You don't want to reformat or repartition often, so you just want to be done with it at once. The easiest is just to setup 2 (two) partitions: one root filesystem big enough for all lunar software, and the rest for <code>/home</code>. Typically, lunar occupies between 4 and 12 gb based on how many applications you install. If you clean up often you can manage with 8gb, but you should keep some extra space. I certainly advise to use a swapfile instead of a swap partition: you can always later delete the swap, or move the swapfile to another disk or partition. A swap partition is harder to relocate.

''Servers'' have different needs. First of all <code>/home</code> doesn't need to be that large, but you will want to setup space for logfiles that cannot cause problems if they grow too fast. Putting <code>/var/tmp</code> and <code>/var/log</code> on separate partitions is quite normal. <code>/tmp</code> can be abused similarly, and is mostly run in [[tmpfs]] to avoid cluttering and give fast access times. Then <code>/usr</code> will be separate and the usual separate <code>rootfs</code>. As you can see this list is already getting quite big! Most users will actually want to make the <code>rootfs</code> quite small (as small as 200mb sometimes!) and thus <code>/home</code> also needs to be on a separate partition.

===Kernel features, built-in or module?===
When I compile a kernel, should I compile drivers that I need in the kernel image or as module?

'''Answer:'''

There are many schools of thought on kernel compiling. One is to build everything into the main kernel without modules. The other one takes building modules to the extreme. Here is a suggestion, if it's not needed to boot it's a module. Thus usb, input, sound, mice ACPI, network, and also cdrom, floppy, and all the non boot file systems, all get built as modules. This reduces the size of the main kernel so it can be put on a floppy. Another thing to consider is that not everything works perfectly, and some features can cause your kernel to misbehave, so if some feature is built-in, the bad behavior is practically inevitible. Instead, with a module you can choose not to load it and thus be left with a working system.

Please note that some people need to make some features built into their kernel and vice versa, do whatever works best for you.

===QEMU and Lunar ISO testing===
How do I use qemu to try out lunar ISO's?

'''Answer:'''

Just a quick note on how to use qemu for testing a Lunar Linux installation. See <code>/var/lib/lunar/moonbase/devel/qemu/DETAILS</code> for a description of qemu. Think of it as a low-cost (''read: free'') version of a virtual machine, that has quite a few useful features and is under active development.

A very simple way to just test a Lunar ISO for booting purposes is:

qemu -cdrom lunar-1.5.0-i686.iso -boot d

If you want to test a full install, then create a 512 megabyte sparse root_fs image with this <code>dd</code> command:

dd if=/dev/zero of=hda.img bs=$((1024 * 1024)) count=0 seek=512

Now invoke qemu:

qemu -cdrom lunar-1.5.0-i686.iso -boot d -hda hda.img

You can then proceed to test your Lunar install. Refer the qemu homepage for further tips and tricks. qemu can also be quite easily used to test if your brand new kernel is bootable or not, which is quite neat.

Note that you should say yes to using SDL as an optional_depends. The gui version of qemu is ''very'' nice in its own little X11 window.

==Other==

===How do I unpack an .RPM file in lunar?===
How do I install RPM files in lunar? Is that possible?

'''Answer:'''

The easiest way to unpack a rpm file is to use the module called <code>rpmunpack</code>. Simply run <code>rpmupack ''XYZ''.rpm</code> for your RPM. This will create a cpio file (''XYZ.cpio.gz'' and ''XYZ.cpio.bz2'' are not uncommon). Once you perform any additional uncompression with <code>gunzip</code> or <code>bunzip2</code>, you can then extract it using <code>cpio -i -d < XYZ.cpio</code> -- After all that you should be all done. If you are trying to rpmunpack a source RPM (i.e. .src.rpm) file then ''XYZ.cpio'' may further contain a tar.bz2 or tar.gz source tarball.

In the zbeta section of moonbase, there is an '''''unsupported''''' module called <code>rpm</code> for those of you that are really desperate.

You might want to do <code>man cpio</code>, to check out additional cpio parameters that may interest you, such as the -L switch.

===What is that in the Lunar-Linux logo?===
What is that logo of yours? It looks like a <nowiki>[cat|ferret|dog|owl|insert nutty animal here]</nowiki>!

'''Answer:'''

The logo is a [[wikipedia:Southern Rockhopper Penguin|Rockhopper Penguin]]. It's a kind of nasty penguin, the one that crowd up in thousands to take over the continent. They have a few long feathers sticking out at their "ears" sideway, just like some owl species do.

You can check out [http://images.google.com/images?q=Rockhopper+Penguin Google Images] for lots of Rockhopper Penguin pictures!

Moonbase:module

2006-04-22T19:18:21Z

Sofar: Reverted edit of Android18, changed back to last version by Engelsman

==Module==

General term for the package installation and compilation instructions used in [[Lunar Linux]]. All [[modules]] together make up the [[moonbase]].

===Definition===
A module is defined as ''a directory in [[moonbase]] that contains a [[DETAILS]] file''.

Module Basics

2006-03-27T22:45:52Z

Sofar: more spam. bah.

__TOC__

In ''lunar'' parlance, software packages are called [[modules]]. The collection of all modules is the [[moonbase]], which is simply a directory (usually <code>/var/lib/lunar/moonbase</code>) containing ''sections'' (i.e. directories) which in turn contain the [[module]] directories.

A module is simply a directory containing the scripts necessary to build a software package, and optionally configuration files which may be needed in <code>/etc</code>. Some modules require only a [[DETAILS]] file, however this is only the case for a few of the modules in the entire moonbase. In each case, after [[DETAILS]], [[DEPENDS]], and [[CONFIGURE]], where a module can use lunar's default internal function(s), there is no need for a module-specific script.

* [[DETAILS]] sets version, source URL(s) and other critical data
* [[CONFLICTS]] specifies modules which must (will) be removed by module
* [[CONFIGURE]] interactive script where build options can be set
* [[DEPENDS]] specifies required and optional packages
* [[PRE_REMOVE]] used by [[lrm]]; actions which must preceed removal
* [[PRE_BUILD]] most often used for patching, unpacking addional source tarballs
* [[BUILD]] runs necessary variations on: configure; make; make install
* [[POST_BUILD]] install configuration scripts and data.
* [[POST_INSTALL]] messages, notes more cleanups, configuration fixes
* [[POST_REMOVE]] used by [[lrm]]; actions which must follow removal

== Package Build and Install Scripts ==

The following scripts are used by [[lin]] or indirectly by [[lunar]] when building modules.

=== The DETAILS script ===

Every module is required to have at least a [[DETAILS]] file. A minimal [[DETAILS]] may appear as follows: (<code>/var/lib/lunar/moonbase/editors/emacs/DETAILS</code>)

MODULE=emacs
VERSION=21.3
SOURCE=$MODULE-$VERSION.tar.gz
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION
SOURCE_URL=$GNU_URL/$MODULE/$SOURCE
SOURCE_URL=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE/$SOURCE</nowiki>
SOURCE_VFY=md5:a0bab457cbf5b4f8eb99d1d0a3ada420
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki>
ENTERED=20010922
UPDATED=20020529
SHORT="Emacs is the extensible, self-documenting real-time display editor."
cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

With comments, default values:

MODULE=emacs # Module name, yes it's redundant
VERSION=21.3 # Version, changes *often*
SOURCE=$MODULE-$VERSION.tar.gz # Source filename
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION # Where source unpacks
# ($BUILD_DIRECTORY=/usr/src)
SOURCE_URL[0]=$GNU_URL/$MODULE/$SOURCE # Download URL
SOURCE_URL[1]=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE/$SOURCE</nowiki> # Alternate URL(s)
SOURCE_VFY=md5:a0bab457cbf5b4f8eb99d1d0a3ada420 # Sets md5 hash or pgp/gpg sig url
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki> # where to learn more
ENTERED=20010922 # First appearance in moonbase
UPDATED=20020529 # Date of latest change.
# Force update by setting this

# The remaining lines are used for input to the 'lvu what' command
# and are best copied from the source-maintainer's own description.

SHORT="Emacs is the extensible, self-documenting real-time display editor."
cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

=== The DEPENDS script ===

The [[DEPENDS]] script is essential to configuration management, and is the key to the overall operation of lunar. Dependencies should be exactly specified, preferably not assuming the presence of any other modules, while knowing the sub-dependencies of the modules which are added and not adding those explictly where not needed.

'''Warning''' - Getting this right is difficult. Because the state of installed packages may vary widely, it's important to have a good understanding of what might be or not be installed on a target system.

'''Note''' - By convention Lunar does not include the X Window System, xfree86 or XOrg, in any dependency. There are two reasons for this choice. First we expect that users must understand that to use a graphical application locally, the X Window System must be installed. Second, due to the sligtly unusual definition of client and server used by X11, it is often in fact possible to build graphical applications and tools for remote display, without the server components locally installed. At some future date we may elect to provide a client-only installation of xfree86.

[[DEPENDS]] may include both required and optional dependencies. The '''depends()''' function statement simply determines one required package. The optional_depends function is a little more complex. It consists of the required package, necessary --options to give to <code>./configure</code> for yes and no respectively, and an explanatory comment telling the user the purpose of the option being presented. A typical [[DEPENDS]] file might appear as follows: (<code>/var/lib/lunar/moonbase/devel/subversion/DEPENDS</code>)

depends zlib &&
depends openssl &&
optional_depends "db4" "--with-berkeley-db" "" "for creating local repositories"
# ^ ^ ^ ^
# | | | |
# optional package if "Y" if "N" explanatory comment
# { ./configure strings }

'''Aliases'''

Aliases are a mean to select a generic module. When you need a functionnality that can be provided by two or more softwares, you can select one of them to provide a correct dependency.

Example /var/lib/lunar/moonbase/aliases:
<code>
%APACHE:apache apache2 apache-mod_ssl
%FAM:fam gamin
%GECKO_RENDERER: firefox thunderbird mozilla
%GHOSTSCRIPT:espgs ghostscript
%MTA:postfix exim sendmail esmtp
%SLANG:slang slang2
%X:XOrg XOrg-test xfree86 xfree86-beta
%XMLRENDERER: libxml2 expat
%XSCREENSAVER:xscreensaver xscreensaver-gtk1 xscreensaver-kde
</code>

For example you can choose %X instead of XOrg in a module that would depends on any X server:
<code>
depends %X
</code>

=== The CONFLICTS script ===

This script is simply used to specify modules which will be removed when a given module is installed. An example would be: (<code>/var/lib/lunar/moonbase/editors/elvis/CONFLICTS</code>)

conflicts vim

=== The CONFIGURE script ===

The [[CONFIGURE]] script is used to collect interactive input from the user on optional parameters for the software build. use the '''query''' function and provide a default answer to each question. The results of the answers are then used to store configuration variables needed in configuration state files. An a simple example might be: (<code>/var/lib/lunar/moonbase/crypto/gnupg/CONFIGURE</code>)

if ! grep -q CONFIGURED $MODULE_CONFIG ; then
if query "Enable experimental external HKP keyserver interface? " n ; then
OPTS="$OPTS --enable-external-hkp"
fi
echo 'CONFIGURED="y"' >> $MODULE_CONFIG
fi

Another way is using '''mquery''' like the lilo module does:

mquery RUN_LILO "Run LILO automatically upon LILO upgrades?" y

=== The PRE_BUILD script ===

[[PRE_BUILD]] is used where special processing is needed before undertaking the actual build steps. Typical requirements include unpacking multiple sources, creating necessary system or source-tree direcotries and applying source patches. And example would be: (<code>/var/lib/lunar/moonbase/doc-tools/html2db/PRE_BUILD</code>)

mk_source_dir $SOURCE_DIRECTORY &&
unpack $SOURCE &&
cd $MODULE
unpack $SOURCE2
cd tidy
patch_it $SOURCE_CACHE/$SOURCE3 0
cd /usr/src/$MODULE

=== The BUILD script ===

[[BUILD]] is used where the '''default_build()''' function does not work for a given software package. For reference the commands run by default are:

Function '''default_build()''' calls '''default_config''' which executes:

./configure --build=$BUILD \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--infodir=/usr/share/info \
--mandir=/usr/share/man \
$OPTS

Next, '''default_build()''' calls '''default_make''' which executes:

make &&
prepare_install &&
make install

Where this build configuration does not work, the [[BUILD]] script is used to provide the needed steps. About 75% of modules need a [[BUILD]] script. Two examples include: (<code>/var/lib/lunar/moonbase/archive/gzip/BUILD</code>)

(
./configure --build=$BUILD \
--prefix=/usr \
--bindir=/bin \
--infodir=/usr/share/info \
--mandir=/usr/share/man &&
make &&
prepare_install &&
make bindir=/bin install
) > $C_FIFO 2>&1

and: (<code>/var/lib/lunar/moonbase/editors/ex/BUILD</code>)

(
cd $SOURCE_DIRECTORY &&
sedit 's/usr.local/usr/' Makefile &&
sedit 's/= man/= share\/man/' Makefile &&
sedit 's/ucb/bin/' Makefile &&
sedit 's/= termlib/= ncurses/' Makefile &&
make &&
prepare_install &&
make install
) > $C_FIFO 2>&1

The first example is a build which needs non-standard 'configure' and 'make install' commands. The second is a build which does not use gnu auto-tools' 'configure' script.

'''Note''' - [[BUILD]] scripts must execute inside a (), called a subshell invocation, construct and output is always directed to a named pipe (aka FIFO). Therefor all [[BUILD]] files take the follwing form:

(
# commands are put here
) > $C_FIFO 2>&1 # $C_FIFO holds the name of a fifo in /tmp used for 'voyeur'

=== The POST_BUILD script ===

[[POST_BUILD]] runs in place of the '''default_post_build''' routine which is used to install minor documentation and transfer/enable initialization scripts and similar system data, mostly into <code>/etc</code>.

[[POST_BUILD]] script usage is '''deprecated'''. You should install your config files in [[BUILD]] (remember not to overwrite previous config files!) or install defaults from [[POST_INSTALL]] (again, do not overwrite present files!). The ability to use a [[POST_BUILD]] script is purely for certain internal functions.

=== The POST_INSTALL script ===

[[POST_INSTALL]] has no equivalent functions, and is run to handle post-installation work in a general manner. An example is: (<code>/var/lib/lunar/moonbase/compilers/gcc/POST_INSTALL</code>)

cd /usr/lib/gcc-lib/$BUILD/$VERSION &&
ln -sf /usr/bin/cpp cpp &&
cd /lib/ &&
ln -sf /usr/bin/cpp cpp &&
if [ ! -e /usr/bin/cc ] ; then
ln -s gcc /usr/bin/cc
fi

== Package Removal Scripts ==

Module removal is handled by [[lrm]]. Because installation is monitored and backup tarballs are created using installwatch, most of package removal is handled automatically using the logs created by installwatch. However we provide for additional actions to be taken through the [[PRE_REMOVE]] and [[POST_REMOVE]] scripts.

=== The PRE_REMOVE script ===

[[PRE_REMOVE]] is needed to execute any tasks needed prior to the main task of removing all files installed by the module. An example would be: (<code>/var/lib/lunar/moonbase/mail/docbook-3.1/PRE_REMOVE</code>)

CENTRALIZED=/etc/sgml/catalog
DOCBOOK_INSTALL_DIR=/usr/share/sgml/docbook/$VERSION
install-catalog -r $CENTRALIZED $DOCBOOK_INSTALL_DIR/catalog

=== The POST_REMOVE Script ===

[[POST_REMOVE]] may be used to remove data not tracked by installwatch and to correctly adjust remaining configuration files and data. Examples would include: (<code>/var/lib/lunar/moonbase/devel/binutils/POST_REMOVE</code>)

install-info --delete as --info-dir /usr/info
install-info --delete bfd --info-dir /usr/info
install-info --delete binutils --info-dir /usr/info
install-info --delete configure --info-dir /usr/info
install-info --delete gasp --info-dir /usr/info
install-info --delete gprof --info-dir /usr/info
install-info --delete ld --info-dir /usr/info

or: (<code>/var/lib/lunar/moonbase/compilers/php/POST_REMOVE</code>)

if module_installed apache; then
cp /etc/httpd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpd/httpd.conf
rm -f /tmp/httpd.conf
elif module_installed apache_mod_ssl; then
cp /etc/httpsd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpsd/httpd.conf
rm -f /tmp/httpd.conf
fi

Module Basics

2006-03-07T04:36:22Z

Sofar: /* The BUILD script */

Module Basics

2006-03-07T02:38:14Z

Sofar: /* The POST_BUILD script */

__TOC__

In ''lunar'' parlance, software packages are called [[modules]]. The collection of all modules is the [[moonbase]], which is simply a directory (usually <code>/var/lib/lunar/moonbase</code>) containing ''sections'' (i.e. directories) which in turn contain the [[module]] directories.

A module is simply a directory containing the scripts necessary to build a software package, and optionally configuration files which may be needed in <code>/etc</code>. Some modules require only a [[DETAILS]] file, however this is only the case for a few of the modules in the entire moonbase. In each case, after [[DETAILS]], [[DEPENDS]], and [[CONFIGURE]], where a module can use lunar's default internal function(s), there is no need for a module-specific script.

* [[DETAILS]] sets version, source URL(s) and other critical data
* [[CONFLICTS]] specifies modules which must (will) be removed by module
* [[CONFIGURE]] interactive script where build options can be set
* [[DEPENDS]] specifies required and optional packages
* [[PRE_REMOVE]] used by [[lrm]]; actions which must preceed removal
* [[PRE_BUILD]] most often used for patching, unpacking addional source tarballs
* [[BUILD]] runs necessary variations on: configure; make; make install
* [[POST_BUILD]] install configuration scripts and data.
* [[POST_INSTALL]] messages, notes more cleanups, configuration fixes
* [[POST_REMOVE]] used by [[lrm]]; actions which must follow removal

== Package Build and Install Scripts ==

The following scripts are used by [[lin]] or indirectly by [[lunar]] when building modules.

=== The DETAILS script ===

Every module is required to have at least a [[DETAILS]] file. A minimal [[DETAILS]] may appear as follows: (<code>/var/lib/lunar/moonbase/editors/emacs/DETAILS</code>)

MODULE=emacs
VERSION=21.3
SOURCE=$MODULE-$VERSION.tar.gz
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION
SOURCE_URL=$GNU_URL/$MODULE/$SOURCE
SOURCE_URL=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE/$SOURCE</nowiki>
SOURCE_VFY=md5:a0bab457cbf5b4f8eb99d1d0a3ada420
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki>
ENTERED=20010922
UPDATED=20020529
SHORT="Emacs is the extensible, self-documenting real-time display editor."
cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

With comments, default values:

MODULE=emacs # Module name, yes it's redundant
VERSION=21.3 # Version, changes *often*
SOURCE=$MODULE-$VERSION.tar.gz # Source filename
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION # Where source unpacks
# ($BUILD_DIRECTORY=/usr/src)
SOURCE_URL[0]=$GNU_URL/$MODULE/$SOURCE # Download URL
SOURCE_URL[1]=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE/$SOURCE</nowiki> # Alternate URL(s)
SOURCE_VFY=md5:a0bab457cbf5b4f8eb99d1d0a3ada420 # Sets md5 hash or pgp/gpg sig url
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki> # where to learn more
ENTERED=20010922 # First appearance in moonbase
UPDATED=20020529 # Date of latest change.
# Force update by setting this

# The remaining lines are used for input to the 'lvu what' command
# and are best copied from the source-maintainer's own description.

SHORT="Emacs is the extensible, self-documenting real-time display editor."
cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

=== The DEPENDS script ===

The [[DEPENDS]] script is essential to configuration management, and is the key to the overall operation of lunar. Dependencies should be exactly specified, preferably not assuming the presence of any other modules, while knowing the sub-dependencies of the modules which are added and not adding those explictly where not needed.

'''Warning''' - Getting this right is difficult. Because the state of installed packages may vary widely, it's important to have a good understanding of what might be or not be installed on a target system.

'''Note''' - By convention Lunar does not include the X Window System, xfree86 or XOrg, in any dependency. There are two reasons for this choice. First we expect that users must understand that to use a graphical application locally, the X Window System must be installed. Second, due to the sligtly unusual definition of client and server used by X11, it is often in fact possible to build graphical applications and tools for remote display, without the server components locally installed. At some future date we may elect to provide a client-only installation of xfree86.

[[DEPENDS]] may include both required and optional dependencies. The '''depends()''' function statement simply determines one required package. The optional_depends function is a little more complex. It consists of the required package, necessary --options to give to <code>./configure</code> for yes and no respectively, and an explanatory comment telling the user the purpose of the option being presented. A typical [[DEPENDS]] file might appear as follows: (<code>/var/lib/lunar/moonbase/devel/subversion/DEPENDS</code>)

depends zlib &&
depends openssl &&
optional_depends "db4" "--with-berkeley-db" "" "for creating local repositories"
# ^ ^ ^ ^
# | | | |
# optional package if "Y" if "N" explanatory comment
# { ./configure strings }

'''Aliases'''

Aliases are a mean to select a generic module. When you need a functionnality that can be provided by two or more softwares, you can select one of them to provide a correct dependency.

Example /var/lib/lunar/moonbase/aliases:
<code>
%APACHE:apache apache2 apache-mod_ssl
%FAM:fam gamin
%GECKO_RENDERER: firefox thunderbird mozilla
%GHOSTSCRIPT:espgs ghostscript
%MTA:postfix exim sendmail esmtp
%SLANG:slang slang2
%X:XOrg XOrg-test xfree86 xfree86-beta
%XMLRENDERER: libxml2 expat
%XSCREENSAVER:xscreensaver xscreensaver-gtk1 xscreensaver-kde
</code>

For example you can choose %X instead of XOrg in a module that would depends on any X server:
<code>
depends %X
</code>

=== The CONFLICTS script ===

This script is simply used to specify modules which will be removed when a given module is installed. An example would be: (<code>/var/lib/lunar/moonbase/editors/elvis/CONFLICTS</code>)

conflicts vim

=== The CONFIGURE script ===

The [[CONFIGURE]] script is used to collect interactive input from the user on optional parameters for the software build. use the '''query''' function and provide a default answer to each question. The results of the answers are then used to store configuration variables needed in configuration state files. An a simple example might be: (<code>/var/lib/lunar/moonbase/crypto/gnupg/CONFIGURE</code>)

if ! grep -q CONFIGURED $MODULE_CONFIG ; then
if query "Enable experimental external HKP keyserver interface? " n ; then
OPTS="$OPTS --enable-external-hkp"
fi
echo 'CONFIGURED="y"' >> $MODULE_CONFIG
fi

Another way is using '''mquery''' like the lilo module does:

mquery RUN_LILO "Run LILO automatically upon LILO upgrades?" y

=== The PRE_BUILD script ===

[[PRE_BUILD]] is used where special processing is needed before undertaking the actual build steps. Typical requirements include unpacking multiple sources, creating necessary system or source-tree direcotries and applying source patches. And example would be: (<code>/var/lib/lunar/moonbase/doc-tools/html2db/PRE_BUILD</code>)

mk_source_dir $SOURCE_DIRECTORY &&
unpack $SOURCE &&
cd $MODULE
unpack $SOURCE2
cd tidy
patch_it $SOURCE_CACHE/$SOURCE3 0
cd /usr/src/$MODULE

=== The BUILD script ===

[[BUILD]] is used where the '''default_build()''' function does not work for a given software package. For reference the commands run by default are:

Function '''default_build()''' calls '''default_config''' which executes:

./configure --build=$BUILD \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--infodir=/usr/share/info \
--mandir=/usr/share/man \
$OPTS

Next, '''default_build()''' calls '''default_make''' which executes:

make &&
make install

Where this build configuration does not work, the [[BUILD]] script is used to provide the needed steps. About 75% of modules need a [[BUILD]] script. Two examples include: (<code>/var/lib/lunar/moonbase/archive/gzip/BUILD</code>)

(
./configure --build=$BUILD \
--prefix=/usr \
--bindir=/bin \
--infodir=/usr/share/info \
--mandir=/usr/share/man &&
make &&
prepare_install &&
make bindir=/bin install
) > $C_FIFO 2>&1

and: (<code>/var/lib/lunar/moonbase/editors/ex/BUILD</code>)

(
cd $SOURCE_DIRECTORY &&
sedit 's/usr.local/usr/' Makefile &&
sedit 's/= man/= share\/man/' Makefile &&
sedit 's/ucb/bin/' Makefile &&
sedit 's/= termlib/= ncurses/' Makefile &&
make &&
prepare_install &&
make install
) > $C_FIFO 2>&1

The first example is a build which needs non-standard 'configure' and 'make install' commands. The second is a build which does not use gnu auto-tools' 'configure' script.

'''Note''' - [[BUILD]] scripts must execute inside a (), called a subshell invocation, construct and output is always directed to a named pipe (aka FIFO). Therefor all [[BUILD]] files take the follwing form:

(
# commands are put here
) > $C_FIFO 2>&1 # $C_FIFO holds the name of a fifo in /tmp used for 'voyeur'

=== The POST_BUILD script ===

[[POST_BUILD]] runs in place of the '''default_post_build''' routine which is used to install minor documentation and transfer/enable initialization scripts and similar system data, mostly into <code>/etc</code>.

[[POST_BUILD]] script usage is '''deprecated'''. You should install your config files in [[BUILD]] (remember not to overwrite previous config files!) or install defaults from [[POST_INSTALL]] (again, do not overwrite present files!). The ability to use a [[POST_BUILD]] script is purely for certain internal functions.

=== The POST_INSTALL script ===

[[POST_INSTALL]] has no equivalent functions, and is run to handle post-installation work in a general manner. An example is: (<code>/var/lib/lunar/moonbase/compilers/gcc/POST_INSTALL</code>)

cd /usr/lib/gcc-lib/$BUILD/$VERSION &&
ln -sf /usr/bin/cpp cpp &&
cd /lib/ &&
ln -sf /usr/bin/cpp cpp &&
if [ ! -e /usr/bin/cc ] ; then
ln -s gcc /usr/bin/cc
fi

== Package Removal Scripts ==

Module removal is handled by [[lrm]]. Because installation is monitored and backup tarballs are created using installwatch, most of package removal is handled automatically using the logs created by installwatch. However we provide for additional actions to be taken through the [[PRE_REMOVE]] and [[POST_REMOVE]] scripts.

=== The PRE_REMOVE script ===

[[PRE_REMOVE]] is needed to execute any tasks needed prior to the main task of removing all files installed by the module. An example would be: (<code>/var/lib/lunar/moonbase/mail/docbook-3.1/PRE_REMOVE</code>)

CENTRALIZED=/etc/sgml/catalog
DOCBOOK_INSTALL_DIR=/usr/share/sgml/docbook/$VERSION
install-catalog -r $CENTRALIZED $DOCBOOK_INSTALL_DIR/catalog

=== The POST_REMOVE Script ===

[[POST_REMOVE]] may be used to remove data not tracked by installwatch and to correctly adjust remaining configuration files and data. Examples would include: (<code>/var/lib/lunar/moonbase/devel/binutils/POST_REMOVE</code>)

install-info --delete as --info-dir /usr/info
install-info --delete bfd --info-dir /usr/info
install-info --delete binutils --info-dir /usr/info
install-info --delete configure --info-dir /usr/info
install-info --delete gasp --info-dir /usr/info
install-info --delete gprof --info-dir /usr/info
install-info --delete ld --info-dir /usr/info

or: (<code>/var/lib/lunar/moonbase/compilers/php/POST_REMOVE</code>)

if module_installed apache; then
cp /etc/httpd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpd/httpd.conf
rm -f /tmp/httpd.conf
elif module_installed apache_mod_ssl; then
cp /etc/httpsd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpsd/httpd.conf
rm -f /tmp/httpd.conf
fi

Module Basics

2006-03-07T02:32:40Z

Sofar: /* The POST_BUILD script */

__TOC__

In ''lunar'' parlance, software packages are called [[modules]]. The collection of all modules is the [[moonbase]], which is simply a directory (usually <code>/var/lib/lunar/moonbase</code>) containing ''sections'' (i.e. directories) which in turn contain the [[module]] directories.

A module is simply a directory containing the scripts necessary to build a software package, and optionally configuration files which may be needed in <code>/etc</code>. Some modules require only a [[DETAILS]] file, however this is only the case for a few of the modules in the entire moonbase. In each case, after [[DETAILS]], [[DEPENDS]], and [[CONFIGURE]], where a module can use lunar's default internal function(s), there is no need for a module-specific script.

* [[DETAILS]] sets version, source URL(s) and other critical data
* [[CONFLICTS]] specifies modules which must (will) be removed by module
* [[CONFIGURE]] interactive script where build options can be set
* [[DEPENDS]] specifies required and optional packages
* [[PRE_REMOVE]] used by [[lrm]]; actions which must preceed removal
* [[PRE_BUILD]] most often used for patching, unpacking addional source tarballs
* [[BUILD]] runs necessary variations on: configure; make; make install
* [[POST_BUILD]] install configuration scripts and data.
* [[POST_INSTALL]] messages, notes more cleanups, configuration fixes
* [[POST_REMOVE]] used by [[lrm]]; actions which must follow removal

== Package Build and Install Scripts ==

The following scripts are used by [[lin]] or indirectly by [[lunar]] when building modules.

=== The DETAILS script ===

Every module is required to have at least a [[DETAILS]] file. A minimal [[DETAILS]] may appear as follows: (<code>/var/lib/lunar/moonbase/editors/emacs/DETAILS</code>)

MODULE=emacs
VERSION=21.3
SOURCE=$MODULE-$VERSION.tar.gz
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION
SOURCE_URL=$GNU_URL/$MODULE/$SOURCE
SOURCE_URL=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE/$SOURCE</nowiki>
SOURCE_VFY=md5:a0bab457cbf5b4f8eb99d1d0a3ada420
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki>
ENTERED=20010922
UPDATED=20020529
SHORT="Emacs is the extensible, self-documenting real-time display editor."
cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

With comments, default values:

MODULE=emacs # Module name, yes it's redundant
VERSION=21.3 # Version, changes *often*
SOURCE=$MODULE-$VERSION.tar.gz # Source filename
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION # Where source unpacks
# ($BUILD_DIRECTORY=/usr/src)
SOURCE_URL[0]=$GNU_URL/$MODULE/$SOURCE # Download URL
SOURCE_URL[1]=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE/$SOURCE</nowiki> # Alternate URL(s)
SOURCE_VFY=md5:a0bab457cbf5b4f8eb99d1d0a3ada420 # Sets md5 hash or pgp/gpg sig url
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki> # where to learn more
ENTERED=20010922 # First appearance in moonbase
UPDATED=20020529 # Date of latest change.
# Force update by setting this

# The remaining lines are used for input to the 'lvu what' command
# and are best copied from the source-maintainer's own description.

SHORT="Emacs is the extensible, self-documenting real-time display editor."
cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

=== The DEPENDS script ===

The [[DEPENDS]] script is essential to configuration management, and is the key to the overall operation of lunar. Dependencies should be exactly specified, preferably not assuming the presence of any other modules, while knowing the sub-dependencies of the modules which are added and not adding those explictly where not needed.

'''Warning''' - Getting this right is difficult. Because the state of installed packages may vary widely, it's important to have a good understanding of what might be or not be installed on a target system.

'''Note''' - By convention Lunar does not include the X Window System, xfree86 or XOrg, in any dependency. There are two reasons for this choice. First we expect that users must understand that to use a graphical application locally, the X Window System must be installed. Second, due to the sligtly unusual definition of client and server used by X11, it is often in fact possible to build graphical applications and tools for remote display, without the server components locally installed. At some future date we may elect to provide a client-only installation of xfree86.

[[DEPENDS]] may include both required and optional dependencies. The '''depends()''' function statement simply determines one required package. The optional_depends function is a little more complex. It consists of the required package, necessary --options to give to <code>./configure</code> for yes and no respectively, and an explanatory comment telling the user the purpose of the option being presented. A typical [[DEPENDS]] file might appear as follows: (<code>/var/lib/lunar/moonbase/devel/subversion/DEPENDS</code>)

depends zlib &&
depends openssl &&
optional_depends "db4" "--with-berkeley-db" "" "for creating local repositories"
# ^ ^ ^ ^
# | | | |
# optional package if "Y" if "N" explanatory comment
# { ./configure strings }

'''Aliases'''

Aliases are a mean to select a generic module. When you need a functionnality that can be provided by two or more softwares, you can select one of them to provide a correct dependency.

Example /var/lib/lunar/moonbase/aliases:
<code>
%APACHE:apache apache2 apache-mod_ssl
%FAM:fam gamin
%GECKO_RENDERER: firefox thunderbird mozilla
%GHOSTSCRIPT:espgs ghostscript
%MTA:postfix exim sendmail esmtp
%SLANG:slang slang2
%X:XOrg XOrg-test xfree86 xfree86-beta
%XMLRENDERER: libxml2 expat
%XSCREENSAVER:xscreensaver xscreensaver-gtk1 xscreensaver-kde
</code>

For example you can choose %X instead of XOrg in a module that would depends on any X server:
<code>
depends %X
</code>

=== The CONFLICTS script ===

This script is simply used to specify modules which will be removed when a given module is installed. An example would be: (<code>/var/lib/lunar/moonbase/editors/elvis/CONFLICTS</code>)

conflicts vim

=== The CONFIGURE script ===

The [[CONFIGURE]] script is used to collect interactive input from the user on optional parameters for the software build. use the '''query''' function and provide a default answer to each question. The results of the answers are then used to store configuration variables needed in configuration state files. An a simple example might be: (<code>/var/lib/lunar/moonbase/crypto/gnupg/CONFIGURE</code>)

if ! grep -q CONFIGURED $MODULE_CONFIG ; then
if query "Enable experimental external HKP keyserver interface? " n ; then
OPTS="$OPTS --enable-external-hkp"
fi
echo 'CONFIGURED="y"' >> $MODULE_CONFIG
fi

Another way is using '''mquery''' like the lilo module does:

mquery RUN_LILO "Run LILO automatically upon LILO upgrades?" y

=== The PRE_BUILD script ===

[[PRE_BUILD]] is used where special processing is needed before undertaking the actual build steps. Typical requirements include unpacking multiple sources, creating necessary system or source-tree direcotries and applying source patches. And example would be: (<code>/var/lib/lunar/moonbase/doc-tools/html2db/PRE_BUILD</code>)

mk_source_dir $SOURCE_DIRECTORY &&
unpack $SOURCE &&
cd $MODULE
unpack $SOURCE2
cd tidy
patch_it $SOURCE_CACHE/$SOURCE3 0
cd /usr/src/$MODULE

=== The BUILD script ===

[[BUILD]] is used where the '''default_build()''' function does not work for a given software package. For reference the commands run by default are:

Function '''default_build()''' calls '''default_config''' which executes:

./configure --build=$BUILD \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--infodir=/usr/share/info \
--mandir=/usr/share/man \
$OPTS

Next, '''default_build()''' calls '''default_make''' which executes:

make &&
make install

Where this build configuration does not work, the [[BUILD]] script is used to provide the needed steps. About 75% of modules need a [[BUILD]] script. Two examples include: (<code>/var/lib/lunar/moonbase/archive/gzip/BUILD</code>)

(
./configure --build=$BUILD \
--prefix=/usr \
--bindir=/bin \
--infodir=/usr/share/info \
--mandir=/usr/share/man &&
make &&
prepare_install &&
make bindir=/bin install
) > $C_FIFO 2>&1

and: (<code>/var/lib/lunar/moonbase/editors/ex/BUILD</code>)

(
cd $SOURCE_DIRECTORY &&
sedit 's/usr.local/usr/' Makefile &&
sedit 's/= man/= share\/man/' Makefile &&
sedit 's/ucb/bin/' Makefile &&
sedit 's/= termlib/= ncurses/' Makefile &&
make &&
prepare_install &&
make install
) > $C_FIFO 2>&1

The first example is a build which needs non-standard 'configure' and 'make install' commands. The second is a build which does not use gnu auto-tools' 'configure' script.

'''Note''' - [[BUILD]] scripts must execute inside a (), called a subshell invocation, construct and output is always directed to a named pipe (aka FIFO). Therefor all [[BUILD]] files take the follwing form:

(
# commands are put here
) > $C_FIFO 2>&1 # $C_FIFO holds the name of a fifo in /tmp used for 'voyeur'

=== The POST_BUILD script ===

[[POST_BUILD]] runs in place of the '''default_post_build''' routine which is used to install minor documentation and transfer/enable initialization scripts and similar system data, mostly into <code>/etc</code>. An example script would be: (<code>/var/lib/lunar/moonbase/net/samba/POST_BUILD</code>)

if [ ! -d /etc/samba/private ]; then
mkdir -p /etc/samba/private
chmod 700 /etc/samba/private
fi

[[POST_BUILD]] script usage is '''deprecated'''. You should install your config files in [[BUILD]] (remember not to overwrite previous config files!) or install defaults from [[POST_INSTALL]] (again, do not overwrite present files!)

=== The POST_INSTALL script ===

[[POST_INSTALL]] has no equivalent functions, and is run to handle post-installation work in a general manner. An example is: (<code>/var/lib/lunar/moonbase/compilers/gcc/POST_INSTALL</code>)

cd /usr/lib/gcc-lib/$BUILD/$VERSION &&
ln -sf /usr/bin/cpp cpp &&
cd /lib/ &&
ln -sf /usr/bin/cpp cpp &&
if [ ! -e /usr/bin/cc ] ; then
ln -s gcc /usr/bin/cc
fi

== Package Removal Scripts ==

Module removal is handled by [[lrm]]. Because installation is monitored and backup tarballs are created using installwatch, most of package removal is handled automatically using the logs created by installwatch. However we provide for additional actions to be taken through the [[PRE_REMOVE]] and [[POST_REMOVE]] scripts.

=== The PRE_REMOVE script ===

[[PRE_REMOVE]] is needed to execute any tasks needed prior to the main task of removing all files installed by the module. An example would be: (<code>/var/lib/lunar/moonbase/mail/docbook-3.1/PRE_REMOVE</code>)

CENTRALIZED=/etc/sgml/catalog
DOCBOOK_INSTALL_DIR=/usr/share/sgml/docbook/$VERSION
install-catalog -r $CENTRALIZED $DOCBOOK_INSTALL_DIR/catalog

=== The POST_REMOVE Script ===

[[POST_REMOVE]] may be used to remove data not tracked by installwatch and to correctly adjust remaining configuration files and data. Examples would include: (<code>/var/lib/lunar/moonbase/devel/binutils/POST_REMOVE</code>)

install-info --delete as --info-dir /usr/info
install-info --delete bfd --info-dir /usr/info
install-info --delete binutils --info-dir /usr/info
install-info --delete configure --info-dir /usr/info
install-info --delete gasp --info-dir /usr/info
install-info --delete gprof --info-dir /usr/info
install-info --delete ld --info-dir /usr/info

or: (<code>/var/lib/lunar/moonbase/compilers/php/POST_REMOVE</code>)

if module_installed apache; then
cp /etc/httpd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpd/httpd.conf
rm -f /tmp/httpd.conf
elif module_installed apache_mod_ssl; then
cp /etc/httpsd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpsd/httpd.conf
rm -f /tmp/httpd.conf
fi

Tools:lrm

2006-03-05T19:25:29Z

Sofar:

====lrm====

[[tools:lrm|lrm]] is the lunar ''remove'' utility. It does nothing more than remove an installed package from your system.

Tools:lin

2006-03-05T18:58:53Z

Sofar:

====lin====

[[Tools:lin|lin]] is the lunar ''install'' tool. It handles downloading, upgrading (through [[tools:lrm|lrm]], installation and compilation of modules on your system.

To do this, lin follows several steps:

* resolve conflicts - if a package conflicts and is installed, it will prompt the user what to do (remove or keep).
* solve dependencies - if packages are missing, they are inserted into the install queue
* download - the packages are downloaded in the background while processing continues by [[tools:lget|lget]]
* configure options - the user may be prompted for additional configuration questions that affect the way a package is built
* checks - the checksums are checked if available, all sources are downloaded, etc.
* compile - the package is compiled
* upgrade - if a previous version of the package is installed, [[tools:lrm|lrm]] removes the old files in a safe way
* install - the package is physically installed to your system
* post-install actions - several things are done, such as administrativa, documentation, init.d scripts etc.

Tools

2006-03-05T18:51:45Z

Sofar: /* Lunar tools */

==== Lunar tools ====

There is an extra package called [[package:lunar_tools|lunar tools]] that installs extra tools specific to lunar, however those are not discussed here - this page is about the ''lunar coretools''

* [[tools:lunar|lunar]] - does everything - it can be used as a cli or a menu-driven interface to all the other tools
* [[tools:lin|lin]] - installs packages
* [[tools:lrm|lrm]] - removes packages
* [[tools:lvu|lvu]] - viewing utility - shows you information about packages, etc.
* [[tools:lsh|lsh]] - debugging utility - the ''lunar shell''

some deprecated old tools are still available in the core too

* [[tools:lvis|lvis]] - follow a currently compiling program

Tools

2006-03-05T18:51:15Z

Sofar: /* Lunar tools */

==== Lunar tools ====

There is an extra package called [[package:lunar_tools|lunar tools]] that installs extra tools specific to lunar, however those are not discussed here - this page is about the ''lunar coretools''

* [[tools:lunar]] - does everything - it can be used as a cli or a menu-driven interface to all the other tools
* [[tools:lin]] - installs packages
* [[tools:lrm]] - removes packages
* [[tools:lvu]] - viewing utility - shows you information about packages, etc.
* [[tools:lsh]] - debugging utility - the ''lunar shell''

some deprecated old tools are still available in the core too

* [[tools:lvis]] - follow a currently compiling program

Tools

2006-03-05T18:50:33Z

Sofar: tools page

==== Lunar tools ====

There is an extra package called [[package:lunar_tools|lunar tools]] that installs extra tools specific to lunar, however those are not discussed here - this page is about the ''lunar coretools''

* [[lunar]] - does everything - it can be used as a cli or a menu-driven interface to all the other tools
* [[lin]] - installs packages
* [[lrm]] - removes packages
* [[lvu]] - viewing utility - shows you information about packages, etc.
* [[lsh]] - debugging utility - the ''lunar shell''

some deprecated old tools are still available in the core too

* [[lvis]] - follow a currently compiling program

Lunar Linux:About

2006-01-30T16:01:20Z

Sofar: hint towards minimal ISO

'''What is Lunar Linux?'''

Lunar is a source based Linux distribution developed by a very talented team of programmers from all over the world, working together to extend the Linux technology into better-tailored and more optimized software for the end user.

Lunar uses and builds upon the Linux kernel, the software started by Linus Torvalds and supported by thousands of programmers worldwide, and offers a unique package management system which builds each software package, or module, from scratch for the machine in which it is being installed.

This is what sets Lunar apart. It makes customization a breeze-- you choose the compile options before a module is built, and install a lean and uncluttered system that has exactly what you need. Nothing more, or less.

Once installed, Lunar is remarkably fast, breaking new ground in flexibility and in the options it offers the individual user.

'''How have you Licensed it?'''

Lunar-Linux and all it's code are licensed under the GPLv2.

'''How does it work?'''

In a nutshell: Lunar installs a complete bootstrap development system on your machine. You then tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

Lunar's installer is fast and provides full control over the process of installation, including a wide variety of install and rescue tools. The installer provides the user with an interface to compile a custom kernel during installation.

Installing applications is remarkably simple-- type in "lin [package name]" and the system will install the application from the moonbase, our module repository. Don't want it after all? Type "lrm [package name]" and it is gone. Lunar has a unique shell-based Application Management System which handles the dependencies when installing software. There is no "dependency hell"-- if there are other things the system needs to install a particular application, the AMS will simply find them for you.

Updating lunar is a matter of one single command, lunar update. It fetches an updated moonbase, checks if there were any updated modules and builds those. The AMS is network aware and uses the network to acquire source code. The moonbase and core tools are updated every hour at Lunar-Linux.org.
What is the advantage?

The advantage for the end user is clear: a system that is both robust and stable, and easy to install and maintain without sacrificing variety and flexibility. Lunar has built in integrity checking and a robust self-repairing capability. It also enables system users to develop their own source-packages using the toolset.

Lunar is for everyone. Though it may be difficult for the beginner to administer, it provides you with all the possible features you could want from a Linux distribution. It is incredibly accessible to anyone who has played around with a UNIX system.

All of this presents a rich potential for a user who seeks speed, strong performance, and a system that "works smart".
How can I get started?

If you'd like to start using Lunar, you can easily obtain downloads and ISO images from our web site.

You will also need to download our installation manual, which will walk you through everything you need to know about installing Lunar on your machine. As you begin to put Lunar to work, you will find additional resources in our support section, including our FAQ, our Man Pages, and the archives for the Lunar mailing list.

'''What do I get when I install the ISO?'''

The Lunar-Linux ISO installs only a basic set of packages needed to build the rest. There is no GNOME or KDE, not even XOrg on your machine after you finish installing the ISO. The only service running is secure shell (ssh), and root logins are expressly prohibited! However, once you are done installing and have compiled a kernel once to get the kernel sources in /usr/src/linux, you can just `lin XOrg` and start installing your desktop from there!

Allthough this may sound spartan to you, there are still a ton of things you can do with a finished installation. You have links, the text-based webbrowser to surf to webpages. Irssi is installed for IRC chat. The ISO also comes preloaded with a whole bunch of networking tools and hardware utilities (lspci, dmidecode, discover) that allow you to figure out what kind of hardware your system has.

'''So what should I do now?'''

You should either go to the download section or read some more in the library. Follow the links below:

* http://lunar-linux.org/
* http://wiki.lunar-linux.org/

''Copyright 2003, Lunar-Linux.org, written by Suzanne Burns''

''history is irrelevant, only the future matters''

Lunar Linux:About

2006-01-30T15:25:43Z

Sofar: Reverted edit of 200.1.117.23, changed back to last version by 206.131.211.110

'''What is Lunar Linux?'''

Lunar is a source based Linux distribution developed by a very talented team of programmers from all over the world, working together to extend the Linux technology into better-tailored and more optimized software for the end user.

Lunar uses and builds upon the Linux kernel, the software started by Linus Torvalds and supported by thousands of programmers worldwide, and offers a unique package management system which builds each software package, or module, from scratch for the machine in which it is being installed.

This is what sets Lunar apart. It makes customization a breeze-- you choose the compile options before a module is built, and install a lean and uncluttered system that has exactly what you need. Nothing more, or less.

Once installed, Lunar is remarkably fast, breaking new ground in flexibility and in the options it offers the individual user.

'''How have you Licensed it?'''

Lunar-Linux and all it's code are licensed under the GPLv2.

'''How does it work?'''

In a nutshell: Lunar installs a complete bootstrap development system on your machine. You then tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

Lunar's installer is fast and provides full control over the process of installation, including a wide variety of install and rescue tools. The installer provides the user with an interface to compile a custom kernel during installation.

Installing applications is remarkably simple-- type in "lin [package name]" and the system will install the application from the moonbase, our module repository. Don't want it after all? Type "lrm [package name]" and it is gone. Lunar has a unique shell-based Application Management System which handles the dependencies when installing software. There is no "dependency hell"-- if there are other things the system needs to install a particular application, the AMS will simply find them for you.

Updating lunar is a matter of one single command, lunar update. It fetches an updated moonbase, checks if there were any updated modules and builds those. The AMS is network aware and uses the network to acquire source code. The moonbase and core tools are updated every hour at Lunar-Linux.org.
What is the advantage?

The advantage for the end user is clear: a system that is both robust and stable, and easy to install and maintain without sacrificing variety and flexibility. Lunar has built in integrity checking and a robust self-repairing capability. It also enables system users to develop their own source-packages using the toolset.

Lunar is for everyone. Though it may be difficult for the beginner to administer, it provides you with all the possible features you could want from a Linux distribution. It is incredibly accessible to anyone who has played around with a UNIX system.

All of this presents a rich potential for a user who seeks speed, strong performance, and a system that "works smart".
How can I get started?

If you'd like to start using Lunar, you can easily obtain downloads and ISO images from our web site.

You will also need to download our installation manual, which will walk you through everything you need to know about installing Lunar on your machine. As you begin to put Lunar to work, you will find additional resources in our support section, including our FAQ, our Man Pages, and the archives for the Lunar mailing list.

'''So what should I do now?'''

You should either go to the download section or read some more in the library. Follow the links below:

* http://lunar-linux.org/
* http://wiki.lunar-linux.org/

''Copyright 2003, Lunar-Linux.org, written by Suzanne Burns''

''history is irrelevant, only the future matters''

Lunar Linux:FAQ

2005-11-11T23:33:44Z

Sofar: /* configure: error: C preprocessor "/lib/cpp" fails sanity check */

These are the '''F'''requently '''A'''sked '''Q'''uestions for Lunar Linux. You have a question about Lunar? You might get your answer below.<br /><br />

__TOC__

==General==

===What is Lunar Linux?===
What exactly is Lunar Linux?

'''Answer:'''
* Please read [[Lunar Linux:About|About Lunar Linux]].

==Optimizations==

===How do I set optimizations?===
How do I set these optimizations for my machine?

'''Answer:'''

Run <code>lunar optimize</code>. You'll be taken through an interactive menu that explains all the options. Remember to optimize safely.

===What are safe optimizations?===
What are the recomended safe optimizations for [[Lunar Linux]]?

'''Answer:'''

The default sure fire optimizations that are recommended are:

* '''C'''
** <code>-pipe</code>
* '''C++'''
** <code>-pipe</code>
* '''CPU Architecture'''
** You should pick the correct architecture for your own system (defaults to x86 for most people).
* '''Basic Optimzations'''
** Fast (-01) but most people will opt in for Faster, or Fastest (Note that fastest doesn't work on all systems, i.e. k6).
* '''CPU'''
** This, of course, should be set to your own cpu, or the cpu of the machine you plan to run this install on. If you want to be able to run this install on many machines, you should be safe with I586.
* '''Speed Optimizations'''
** If you want to be 100% sure that there won't be optimization problems you shouldn't select any of these.
* '''Extra features'''
** It is not recommended to use any of these optimizations, even for modules known to be able to handle them, since they cause many apps to break.
* '''Floating Point Math'''
** None. If your architecture is x86 and you don't own a 386SX and 486SX, it's safe to select x387.
* '''Linker Options'''
** Strip.
* '''Addon Program Support'''
** CCache. Make sure to install it first.

These settings should work for almost everyone, and there is a lot room for pushing these optimizations more, at the risk of problems with some applications. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations may cause problems?===
What optimizations are known to cause problems in some setups?

'''Answer:'''

Some optimizations that are known to cause problems on x86 with many applications, and even a entire system:

* <code>-funroll-loops</code>
* <code>-fstrict-aliasing</code>
* <code>-ffast-math</code>
* <code>-ffloat-store</code>

These are sorted from the least unstable to most unstable. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations can give some speed without issues?===
What optimizations can I use to gain some speed but without major risks?

'''Answer:'''

Start with the basic optimizations in [[Lunar Linux:FAQ#What_are_safe_optimizations.3F|FAQ #2.2]] and change the Basic Optimizations to Faster or Fastest if you know that gcc will generate correct code for that cpu. -O2 obviously takes more compile time than -O1, and -O3 takes the most time to compile. Then select the cpu you will run it on. Some of the speed optimizations that should be decent and shouldn't cause too many problems, if any, are: -fomit-frame-pointer. A safe bet for floating point math on a x86 would be x387, if you know your cpu has a floating point unit. Check <code>cat /proc/cpuinfo</code> to see if your cpu supports SSE or SSE2. If your cpu does have sse or sse2 then you can also add that to the math optimizations.

Your results may vary. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations should I avoid?===
What optimizations should I stay away from?

'''Answer:'''

All the ones listed in the [[Lunar Linux:FAQ#What_optimizations_may_cause_problems.3F|FAQ #2.3]] plus:
* <code>-fprofile-arcs</code>
* <code>-fbranching-probabilities</code>

Please read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it. The Lunar developers will not respond to bug reports of broken compiles by users with risky optimizations.

==Installing modules==

===Can I compile several modules at once?===
Is it possible to install multiple modules at the same time without breaking things?

'''Answer:'''

Yes, Lunar even promotes it. However doing so will cause installs compile slower of course. Lunar will not install core system modules like gcc and glibc while something else is installing and will wait until the rest is finished. Also, you cannot install applications while those major modules are installing, they will wait their turn until it's safe and continue to install them automatically.

===error : C compiler cannot create executables===
What does this error mean and how can I fix it?
* <code>C compiler cannot create executables</code>

'''Answer:'''

Read the next topic - this is basically the same problem: There are kernel headers missing that are vital to compilation. You will have to restore them. Below is explained how to do that.

===configure: error: C preprocessor "/lib/cpp" fails sanity check===
What does this error mean and how can I fix it?
* <code>configure: error: C preprocessor "/lib/cpp" fails sanity check</code>

'''Answer:'''

This is an include file problem. Sometimes ''/usr/include/gnu/stubs.h'' is missing, this can be found in the glibc source tarball. Most of the time the following applies:

Your kernel headers are missing from <code>/usr/include</code>. This means the C PreProcessor cannot verify that it has the proper cached copies of those vital header files. You need to install the proper ones manually. Here's how:

lin kernel-headers-2.4

This might work for you! (Use the 2.6 version if needed of course)

Otherwise:

mkdir -p /usr/include/{linux,asm}

to create the two target dirs, if needed. Then execute:

cp -av /usr/src/linux/include/linux /usr/include/
cp -av /usr/src/linux/include/asm/* /usr/include/asm/

to copy the files manually. Be warned that the second command has to be done this way since <code>/usr/src/linux/include/asm</code> is a softlink to your arch asm header files, asm points to asm-i386, on x86 machines. So if, on the other hand, you had copied

cp -av /usr/src/linux/include/asm /usr/include/

you would then get a softlink to nowhere under <code>/usr/include/</code>.

Last, you can always try to unpack the kernel tarball you have into <code>/usr/src/linux</code> and manaully link or copy the headers over yourself.

===Can I add more window managers to gdm?===
How do I add other window managers to the sessions list on gdm?

'''Answer:'''

Copy the desktop startup files to <code>/etc/X11/dm/Sessions/</code>. That works with gdm. For kdm you will have to copy them to <code>$KDE_PREFIX/share/apps/kdm/sessions</code>.

===How do I get Flash to work in Mozilla or Firefox?===
How do I get Flash to work in Mozilla or Firefox?

'''Answer:'''

If you are using Mozilla or Firefox, then you can simply do a <code>lin flash-plugin</code> and that will download and install the Macromedia Flash plugin that works with a gtk+ based mozilla through the old abi wrappers.

The flash plugin does ''not'' work with Galeon. The Galeon developers have declined to provide the "old" abi wrappers needed for the plugin to work.

===How do I install Java?===
How do I get Java for my Lunar box?

'''Answer:'''

You will have to download the Java source code from Sun yourself and you have to "click" to agree on their license. You have to compile it yourself too. We don't have a Sun Java module as we currently have no way to automate the "click" to agree to the Sun Java license. See this URL for some handy info:

http://www.linuxfromscratch.org/~tushar/hints/javafromscratch.txt

There is a j2sdk module in moonbase which is the Blackdown port of Sun's Java Virtual Machine.

==Lunar core tools==

===How can I recompile my module with new options?===
How do I force lunar to recompile my modules with different options?

'''Answer:'''

Try:

lin -r ''MODULE''

The -r switch will allow you to select new configuration and dependencies for modules.

===How can I make modules recompile instead of resurrecting?===
How do I tell lunar to recompile my application instead of resurrecting it?

'''Answer:'''

Try doing:

lin -c ''MODULE''

The -c option means tells <code>lin</code> to compile this module even if there is an install cache copy available in <code>/var/cache/lunar</code>.

===My moonbase is gone and I can't install anything.===
How do I fix problems with my moonbase when it's missing or damaged?

'''Answer:'''

Simple solution to this is just running:

lin moonbase

This will download the latest moonbase from the internet, and restore it to working order.

===What is a module?===
What is a [[module]] and what does it do??

'''Answer:'''

A [[module]] is a set of files that tell the core tools the following:

* What name, version, and other properties a package has
* Where to download all needed source files
* What other modules are required, or conflict with this one
* How to unpack the source files, how to patch
* How to configure the code
* How to compile
* How to install everything
* What else to do with it

The [[module]] is coded in a set of files in a directory structure, and scripted in bash.

===What is the Moonbase?===
What is that thing you call [[Moonbase]]?

'''Answer:'''

The [[Moonbase]] is a database with [[modules]]. In this database there are description of packages that tell the core tools where to download, how to compile, and how install a [[module]]. You can consider this the lunar equivalent of portage, grimoire, ports, etc.

===What is theedge?===
What is theedge?

'''Answer:'''

[[theedge]] is the same as lunar, and also known as the core code. Theedge is just another version of lunar. These two pieces of code install your packages, but they do not contain package descriptions. Those are defined in moonbase.

[[Theedge]] is a development version of [[lunar]]. Often there are much more features in theedge, and bugs are fixed quicker as well. However, if you do not like all this tweaking on your system, we advice you to use the stable lunar core tools instead on your system.

You can install [[theedge]] by issuing:

lin theedge

Theedge is automatically updated if you do a <code>lunar renew</code> or <code>lunar update</code>.

==Lunar-Linux Installation==

===So how should I partition my disk?===
I'm setting up lunar from scratch, but how should I partition my disk for a server or desktop system?

'''Answer:'''

Server systems have very different demands than desktops. It's all about flexibility. First desktops:

''desktops'' commonly have one hard disk. You don't want to reformat or repartition often, so you just want to be done with it at once. The easiest is just to setup 2 (two) partitions: one root filesystem big enough for all lunar software, and the rest for <code>/home</code>. Typically, lunar occupies between 4 and 12 gb based on how many applications you install. If you clean up often you can manage with 8gb, but you should keep some extra space. I certainly advise to use a swapfile instead of a swap partition: you can always later delete the swap, or move the swapfile to another disk or partition. A swap partition is harder to relocate.

''Servers'' have different needs. First of all <code>/home</code> doesn't need to be that large, but you will want to setup space for logfiles that cannot cause problems if they grow too fast. Putting <code>/var/tmp</code> and <code>/var/log</code> on separate partitions is quite normal. <code>/tmp</code> can be abused similarly, and is mostly run in [[tmpfs]] to avoid cluttering and give fast access times. Then <code>/usr</code> will be separate and the usual separate <code>rootfs</code>. As you can see this list is already getting quite big! Most users will actually want to make the <code>rootfs</code> quite small (as small as 200mb sometimes!) and thus <code>/home</code> also needs to be on a separate partition.

===Kernel features, built-in or module?===
When I compile a kernel, should I compile drivers that I need in the kernel image or as module?

'''Answer:'''

There are many schools of thought on kernel compiling. One is to build everything into the main kernel without modules. The other one takes building modules to the extreme. Here is a suggestion, if it's not needed to boot it's a module. Thus usb, input, sound, mice ACPI, network, and also cdrom, floppy, and all the non boot file systems, all get built as modules. This reduces the size of the main kernel so it can be put on a floppy. Another thing to consider is that not everything works perfectly, and some features can cause your kernel to misbehave, so if some feature is built-in, the bad behavior is practically inevitible. Instead, with a module you can choose not to load it and thus be left with a working system.

Please note that some people need to make some features built into their kernel and vice versa, do whatever works best for you.

===QEMU and Lunar ISO testing===
How do I use qemu to try out lunar ISO's?

'''Answer:'''

Just a quick note on how to use qemu for testing a Lunar Linux installation. See <code>/var/lib/lunar/moonbase/devel/qemu/DETAILS</code> for a description of qemu. Think of it as a low-cost (''read: free'') version of a virtual machine, that has quite a few useful features and is under active development.

A very simple way to just test a Lunar ISO for booting purposes is:

qemu -cdrom lunar-1.5.0-i686.iso -boot d

If you want to test a full install, then create a 512 megabyte sparse root_fs image with this <code>dd</code> command:

dd if=/dev/zero of=hda.img bs=$((1024 * 1024)) count=0 seek=512

Now invoke qemu:

qemu -cdrom lunar-1.5.0-i686.iso -boot d -hda hda.img

You can then proceed to test your Lunar install. Refer the qemu homepage for further tips and tricks. qemu can also be quite easily used to test if your brand new kernel is bootable or not, which is quite neat.

Note that you should say yes to using SDL as an optional_depends. The gui version of qemu is ''very'' nice in its own little X11 window.

==Other==

===How do I unpack an .RPM file in lunar?===
How do I install RPM files in lunar? Is that possible?

'''Answer:'''

The easiest way to unpack a rpm file is to use the module called <code>rpmunpack</code>. Simply run <code>rpmupack ''XYZ''.rpm</code> for your RPM. This will create a cpio file (''XYZ.cpio.gz'' and ''XYZ.cpio.bz2'' are not uncommon). Once you perform any additional uncompression with <code>gunzip</code> or <code>bunzip2</code>, you can then extract it using <code>cpio -i -d < XYZ.cpio</code> -- After all that you should be all done. If you are trying to rpmunpack a source RPM (i.e. .src.rpm) file then ''XYZ.cpio'' may further contain a tar.bz2 or tar.gz source tarball.

In the zbeta section of moonbase, there is an '''''unsupported''''' module called <code>rpm</code> for those of you that are really desperate.

You might want to do <code>man cpio</code>, to check out additional cpio parameters that may interest you, such as the -L switch.

===What is that in the Lunar-Linux logo?===
What is that logo of yours? It looks like a <nowiki>[cat|ferret|dog|owl|insert nutty animal here]</nowiki>!

'''Answer:'''

The logo is a [[wikipedia:Rock Hopper Penguin|Rock Hopper Penguin]]. It's a kind of nasty penguin, the one that crowd up in thousands to take over the continent. They have a few long feathers sticking out at their "ears" sideway, just like some owl species do.

You can check out [http://images.google.com/images?q=Rock+Hopper+Penguin Google Images] for lots of Rock Hopper Penguin pictures!

Installation:No network

2005-11-11T21:37:50Z

Sofar: Added old howto.

== Installation without a fast network connection ==

Here's a brief howto on how to install Lunar without a fast network (or no network at all!)

Here's the basic steps:

* Get the lunar ISO
* Get a moonbase (here: [[http://lunar-linux.org/lunar/moonbase.tar.bz2]]) and the list of source URLS (here: [[http://download.lunar-linux.org/lunar/mirror-urls.txt]])at the same time
* Download all sources in the URL list and put them on CD-ROM (takes about 5 to 8 CD-ROM's!)
* Go home and install lunar using the ISO
* Insert the sources to your lunar box (they go in /var/spool/lunar), upload the special moonbase to your lunar box and voila

A few notes:

You should download the moonbase tarball and the entire list of download URLs at the same time.

After downloading those two files, start up the download of all the sources from the URLs listed in the mirror-urls.txt. Preferably you should use wget something like this:
~ $ for URL in $(cat mirror-urls.txt) ; do wget -c $URL ; done

Burn these files including the moonbase.tar.bz2 on one, two or three CD's. You can leave out the KDE files if you are not going to use KDE of course, adjust the list as necessary and you see fit

After you went home and performed the first install of lunar the normal way, you have a booting lunar box. From there you can mount the CD-ROM's with all your sources and copy the sources to the place where lunar finds them automatically:
mount /dev/cdrom /mnt/cdrom
cp /mnt/cdrom/* /var/spool/lunar
continue with extracting the moonbase tarball that corresponds with the sources you have downloaded:
cd /var/lib/lunar
mv moonbase/zlocal .zlocal
rm -rf moonbase
tar xjf /var/spool/lunar/moonbase.tar.bz2
mv .zlocal moonbase/zlocal
In order to properly initialize your new moonbase, you should run:
lsh
check_module_index

Note that on theedge code as of 20041126 and newer, you can simply copy the moonbase onto the filesystem and install it with one command:
lget moonbase --url file:///path/to/moonbase.tar.bz2

Now you can lin any module in moonbase without needing to be connected

Note: because it is almost impossible that the URL list file is correct or complete, it may happen that files are missing from the list or are not available for download anymore at the moment you try. You should take into consideration that you may need to walk back and forth work 3 or more times before you have all files you need

Note: if you really have no network, never lin modules as moonbase, lunar or theedge as they always try to download instead of use the source cache in /var/spool/lunar. You might want to check out the syntax for lunar hold

Template:Main Page:Misc

2005-11-11T21:29:54Z

Sofar: Add no-network howto link

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:Misc|}}
</div>

<h2 style="font-variant: small-caps;">[[Lunar Linux:Misc|Other Information]]</h2>

<h4>[[Howto Articles]]</h4>
* [[Installation:No CD|No CD installation]]
* [[Installation:No network|No network installation]]
* [[Installation:Kernel_2.6._HowTo|Installing a 2.6 kernel]]
* [[Installation:The_kernel_commandline_/dev_params_mini-HowTo|The kernel commandline /dev params mini-HowTo]]
* [[Installation:Software Raid|Installation on software RAID]]
* [[Miscellaneous:USB camera howto|USB camera howto]]
* [[Howto Articles|more...]]

<h4>Reviews</h4>
* [http://www.bluefish.se/aquarium/lunar.html Review of Lunar Linux] • by Göran Krampe [http://www.bluefish.se/index.html bluefish.se]
* [http://distrocenter.linux.com/distrocenter/05/07/25/1319212.shtml?tid=127 Lunar Linux Review] • by Preston St Pierre on [http://linux.com/ Linux.com]

<h4>Fun Facts about Lunar</h4>
* [[how_long|How long does it take]] to install something on lunar?

<h4>3rd Party Websites</h4>
* [http://lunar-linux.interhact.net/ Lunar Linux Non-Free Modules]

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux:Misc|More Information]]
</div>

Lunar Linux:FAQ

2005-11-10T18:57:58Z

Sofar: /* Installing modules */ added another common error

These are the '''F'''requently '''A'''sked '''Q'''uestions for Lunar Linux. You have a question about Lunar? You might get your answer below.<br /><br />

__TOC__

==General==

===What is Lunar Linux?===
What exactly is Lunar Linux?

'''Answer:'''
* Please read [[Lunar Linux:About|About Lunar Linux]].

==Optimizations==

===How do I set optimizations?===
How do I set these optimizations for my machine?

'''Answer:'''

Run <code>lunar optimize</code>. You'll be taken through an interactive menu that explains all the options. Remember to optimize safely.

===What are safe optimizations?===
What are the recomended safe optimizations for [[Lunar Linux]]?

'''Answer:'''

The default sure fire optimizations that are recommended are:

* '''C'''
** <code>-pipe</code>
* '''C++'''
** <code>-pipe</code>
* '''CPU Architecture'''
** You should pick the correct architecture for your own system (defaults to x86 for most people).
* '''Basic Optimzations'''
** Fast (-01) but most people will opt in for Faster, or Fastest (Note that fastest doesn't work on all systems, i.e. k6).
* '''CPU'''
** This, of course, should be set to your own cpu, or the cpu of the machine you plan to run this install on. If you want to be able to run this install on many machines, you should be safe with I586.
* '''Speed Optimizations'''
** If you want to be 100% sure that there won't be optimization problems you shouldn't select any of these.
* '''Extra features'''
** It is not recommended to use any of these optimizations, even for modules known to be able to handle them, since they cause many apps to break.
* '''Floating Point Math'''
** None. If your architecture is x86 and you don't own a 386SX and 486SX, it's safe to select x387.
* '''Linker Options'''
** Strip.
* '''Addon Program Support'''
** CCache. Make sure to install it first.

These settings should work for almost everyone, and there is a lot room for pushing these optimizations more, at the risk of problems with some applications. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations may cause problems?===
What optimizations are known to cause problems in some setups?

'''Answer:'''

Some optimizations that are known to cause problems on x86 with many applications, and even a entire system:

* <code>-funroll-loops</code>
* <code>-fstrict-aliasing</code>
* <code>-ffast-math</code>
* <code>-ffloat-store</code>

These are sorted from the least unstable to most unstable. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations can give some speed without issues?===
What optimizations can I use to gain some speed but without major risks?

'''Answer:'''

Start with the basic optimizations in [[Lunar Linux:FAQ#What_are_safe_optimizations.3F|FAQ #2.2]] and change the Basic Optimizations to Faster or Fastest if you know that gcc will generate correct code for that cpu. -O2 obviously takes more compile time than -O1, and -O3 takes the most time to compile. Then select the cpu you will run it on. Some of the speed optimizations that should be decent and shouldn't cause too many problems, if any, are: -fomit-frame-pointer. A safe bet for floating point math on a x86 would be x387, if you know your cpu has a floating point unit. Check <code>cat /proc/cpuinfo</code> to see if your cpu supports SSE or SSE2. If your cpu does have sse or sse2 then you can also add that to the math optimizations.

Your results may vary. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations should I avoid?===
What optimizations should I stay away from?

'''Answer:'''

All the ones listed in the [[Lunar Linux:FAQ#What_optimizations_may_cause_problems.3F|FAQ #2.3]] plus:
* <code>-fprofile-arcs</code>
* <code>-fbranching-probabilities</code>

Please read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it. The Lunar developers will not respond to bug reports of broken compiles by users with risky optimizations.

==Installing modules==

===Can I compile several modules at once?===
Is it possible to install multiple modules at the same time without breaking things?

'''Answer:'''

Yes, Lunar even promotes it. However doing so will cause installs compile slower of course. Lunar will not install core system modules like gcc and glibc while something else is installing and will wait until the rest is finished. Also, you cannot install applications while those major modules are installing, they will wait their turn until it's safe and continue to install them automatically.

===error : C compiler cannot create executables===
What does this error mean and how can I fix it?
* <code>C compiler cannot create executables</code>

'''Answer:'''

Read the next topic - this is basically the same problem: There are kernel headers missing that are vital to compilation. You will have to restore them. Below is explained how to do that.

===configure: error: C preprocessor "/lib/cpp" fails sanity check===
What does this error mean and how can I fix it?
* <code>configure: error: C preprocessor "/lib/cpp" fails sanity check</code>

'''Answer:'''

Your kernel headers are missing from <code>/usr/include</code>. This means the C PreProcessor cannot verify that it has the proper cached copies of those vital header files. You need to install the proper ones manually. Here's how:

lin kernel-headers-2.4

This might work for you! (Use the 2.6 version if needed of course)

Otherwise:

mkdir -p /usr/include/{linux,asm}

to create the two target dirs, if needed. Then execute:

cp -av /usr/src/linux/include/linux /usr/include/
cp -av /usr/src/linux/include/asm/* /usr/include/asm/

to copy the files manually. Be warned that the second command has to be done this way since <code>/usr/src/linux/include/asm</code> is a softlink to your arch asm header files, asm points to asm-i386, on x86 machines. So if, on the other hand, you had copied

cp -av /usr/src/linux/include/asm /usr/include/

you would then get a softlink to nowhere under <code>/usr/include/</code>.

Last, you can always try to unpack the kernel tarball you have into <code>/usr/src/linux</code> and manaully link or copy the headers over yourself.

===Can I add more window managers to gdm?===
How do I add other window managers to the sessions list on gdm?

'''Answer:'''

Copy the desktop startup files to <code>/etc/X11/dm/Sessions/</code>. That works with gdm. For kdm you will have to copy them to <code>$KDE_PREFIX/share/apps/kdm/sessions</code>.

===How do I get Flash to work in Mozilla or Firefox?===
How do I get Flash to work in Mozilla or Firefox?

'''Answer:'''

If you are using Mozilla or Firefox, then you can simply do a <code>lin flash-plugin</code> and that will download and install the Macromedia Flash plugin that works with a gtk+ based mozilla through the old abi wrappers.

The flash plugin does ''not'' work with Galeon. The Galeon developers have declined to provide the "old" abi wrappers needed for the plugin to work.

===How do I install Java?===
How do I get Java for my Lunar box?

'''Answer:'''

You will have to download the Java source code from Sun yourself and you have to "click" to agree on their license. You have to compile it yourself too. We don't have a Sun Java module as we currently have no way to automate the "click" to agree to the Sun Java license. See this URL for some handy info:

http://www.linuxfromscratch.org/~tushar/hints/javafromscratch.txt

There is a j2sdk module in moonbase which is the Blackdown port of Sun's Java Virtual Machine.

==Lunar core tools==

===How can I recompile my module with new options?===
How do I force lunar to recompile my modules with different options?

'''Answer:'''

Try:

lin -r ''MODULE''

The -r switch will allow you to select new configuration and dependencies for modules.

===How can I make modules recompile instead of resurrecting?===
How do I tell lunar to recompile my application instead of resurrecting it?

'''Answer:'''

Try doing:

lin -c ''MODULE''

The -c option means tells <code>lin</code> to compile this module even if there is an install cache copy available in <code>/var/cache/lunar</code>.

===My moonbase is gone and I can't install anything.===
How do I fix problems with my moonbase when it's missing or damaged?

'''Answer:'''

Simple solution to this is just running:

lin moonbase

This will download the latest moonbase from the internet, and restore it to working order.

===What is a module?===
What is a [[module]] and what does it do??

'''Answer:'''

A [[module]] is a set of files that tell the core tools the following:

* What name, version, and other properties a package has
* Where to download all needed source files
* What other modules are required, or conflict with this one
* How to unpack the source files, how to patch
* How to configure the code
* How to compile
* How to install everything
* What else to do with it

The [[module]] is coded in a set of files in a directory structure, and scripted in bash.

===What is the Moonbase?===
What is that thing you call [[Moonbase]]?

'''Answer:'''

The [[Moonbase]] is a database with [[modules]]. In this database there are description of packages that tell the core tools where to download, how to compile, and how install a [[module]]. You can consider this the lunar equivalent of portage, grimoire, ports, etc.

===What is theedge?===
What is theedge?

'''Answer:'''

[[theedge]] is the same as lunar, and also known as the core code. Theedge is just another version of lunar. These two pieces of code install your packages, but they do not contain package descriptions. Those are defined in moonbase.

[[Theedge]] is a development version of [[lunar]]. Often there are much more features in theedge, and bugs are fixed quicker as well. However, if you do not like all this tweaking on your system, we advice you to use the stable lunar core tools instead on your system.

You can install [[theedge]] by issuing:

lin theedge

Theedge is automatically updated if you do a <code>lunar renew</code> or <code>lunar update</code>.

==Lunar-Linux Installation==

===So how should I partition my disk?===
I'm setting up lunar from scratch, but how should I partition my disk for a server or desktop system?

'''Answer:'''

Server systems have very different demands than desktops. It's all about flexibility. First desktops:

''desktops'' commonly have one hard disk. You don't want to reformat or repartition often, so you just want to be done with it at once. The easiest is just to setup 2 (two) partitions: one root filesystem big enough for all lunar software, and the rest for <code>/home</code>. Typically, lunar occupies between 4 and 12 gb based on how many applications you install. If you clean up often you can manage with 8gb, but you should keep some extra space. I certainly advise to use a swapfile instead of a swap partition: you can always later delete the swap, or move the swapfile to another disk or partition. A swap partition is harder to relocate.

''Servers'' have different needs. First of all <code>/home</code> doesn't need to be that large, but you will want to setup space for logfiles that cannot cause problems if they grow too fast. Putting <code>/var/tmp</code> and <code>/var/log</code> on separate partitions is quite normal. <code>/tmp</code> can be abused similarly, and is mostly run in [[tmpfs]] to avoid cluttering and give fast access times. Then <code>/usr</code> will be separate and the usual separate <code>rootfs</code>. As you can see this list is already getting quite big! Most users will actually want to make the <code>rootfs</code> quite small (as small as 200mb sometimes!) and thus <code>/home</code> also needs to be on a separate partition.

===Kernel features, built-in or module?===
When I compile a kernel, should I compile drivers that I need in the kernel image or as module?

'''Answer:'''

There are many schools of thought on kernel compiling. One is to build everything into the main kernel without modules. The other one takes building modules to the extreme. Here is a suggestion, if it's not needed to boot it's a module. Thus usb, input, sound, mice ACPI, network, and also cdrom, floppy, and all the non boot file systems, all get built as modules. This reduces the size of the main kernel so it can be put on a floppy. Another thing to consider is that not everything works perfectly, and some features can cause your kernel to misbehave, so if some feature is built-in, the bad behavior is practically inevitible. Instead, with a module you can choose not to load it and thus be left with a working system.

Please note that some people need to make some features built into their kernel and vice versa, do whatever works best for you.

===QEMU and Lunar ISO testing===
How do I use qemu to try out lunar ISO's?

'''Answer:'''

Just a quick note on how to use qemu for testing a Lunar Linux installation. See <code>/var/lib/lunar/moonbase/devel/qemu/DETAILS</code> for a description of qemu. Think of it as a low-cost (''read: free'') version of a virtual machine, that has quite a few useful features and is under active development.

A very simple way to just test a Lunar ISO for booting purposes is:

qemu -cdrom lunar-1.5.0-i686.iso -boot d

If you want to test a full install, then create a 512 megabyte sparse root_fs image with this <code>dd</code> command:

dd if=/dev/zero of=hda.img bs=$((1024 * 1024)) count=0 seek=512

Now invoke qemu:

qemu -cdrom lunar-1.5.0-i686.iso -boot d -hda hda.img

You can then proceed to test your Lunar install. Refer the qemu homepage for further tips and tricks. qemu can also be quite easily used to test if your brand new kernel is bootable or not, which is quite neat.

Note that you should say yes to using SDL as an optional_depends. The gui version of qemu is ''very'' nice in its own little X11 window.

==Other==

===How do I unpack an .RPM file in lunar?===
How do I install RPM files in lunar? Is that possible?

'''Answer:'''

The easiest way to unpack a rpm file is to use the module called <code>rpmunpack</code>. Simply run <code>rpmupack ''XYZ''.rpm</code> for your RPM. This will create a cpio file (''XYZ.cpio.gz'' and ''XYZ.cpio.bz2'' are not uncommon). Once you perform any additional uncompression with <code>gunzip</code> or <code>bunzip2</code>, you can then extract it using <code>cpio -i -d < XYZ.cpio</code> -- After all that you should be all done. If you are trying to rpmunpack a source RPM (i.e. .src.rpm) file then ''XYZ.cpio'' may further contain a tar.bz2 or tar.gz source tarball.

In the zbeta section of moonbase, there is an '''''unsupported''''' module called <code>rpm</code> for those of you that are really desperate.

You might want to do <code>man cpio</code>, to check out additional cpio parameters that may interest you, such as the -L switch.

===What is that in the Lunar-Linux logo?===
What is that logo of yours? It looks like a <nowiki>[cat|ferret|dog|owl|insert nutty animal here]</nowiki>!

'''Answer:'''

The logo is a [[wikipedia:Rock Hopper Penguin|Rock Hopper Penguin]]. It's a kind of nasty penguin, the one that crowd up in thousands to take over the continent. They have a few long feathers sticking out at their "ears" sideway, just like some owl species do.

You can check out [http://images.google.com/images?q=Rock+Hopper+Penguin Google Images] for lots of Rock Hopper Penguin pictures!

How long

2005-10-17T19:41:35Z

Sofar: /* Estimating compile time */

==[[how_long|How long]] does it take...==
* To install a specific module?
* To install the ISO?
* To recompile all my modules?

These questions get asked a lot by new lunar users and it is a very logical question: Lunar is after all a source distro and requires you to compile all the applications from source, which can sometimes take extremely long!

===Influencing Factors===

* ''System(CPU) speed''
Double the CPU MHz, and you double the amount of instructions that a system can make per time unit. So, as a rule, a faster CPU results in faster compiles.

* ''Memory size''
Compiling may require large amounts of memory, especially when compiling C++ applications. Generally, a compilation will go 50% faster if you have double the memory. So, if you only have 128MB of memory, you will speed up your compiles by 225% by increasing the amount of memory to 512MB. This might be worth the trip to the hardware store.

* ''Idle time''
Compiling takes a long time. Every second that your system is doing something else, especially interactive tasks, reduces the amount of time that your system can compile applications.

* ''System architecture and components''
Needless to say that a compile on a SATA hard disk is a lot faster than on a ATA-33 system. Especially with larger modules this is a very important factor.

===Some basic numbers===

The following numbers are from a Pentium 4 laptop system with 256 MB, running at 1.8GHz. This is a fairly normal system and if you wish to compare it with your own system, you should keep in mind that this system might be relatively slower or faster based on the influencing factors mentioned earlier.

The modules listed below are very common modules, so they should give you some good insight in how long it takes to compile and install something. Based on the size you can make rough estimates for new modules that you wish to install.

module source size installed size compile time
gcc 27.6 257.3 120:45
XOrg 48.2 93.8 68:07
glibc 13.5 64.7 47:09
gtk+-2 11.8 34.5 26:08
perl 9.8 52.3 17:50

As you clearly can see there is some correlation between installed size and compile time, but there are many outliers in this trend: gtk+-2 comes with a lot of bitmaps and documentation, while the XOrg tarball is counted without documentation. The gcc compiler itself has a very elaborate bootstrap phase that takes almost half the time it takes to compile the target compiler. Many many module-specific factors are at work here.

===Estimating compile time===

If you correlate the size of the installed product or the source code size (in compressed form easily available), you get a very loose correlation shown in the graph below:

http://foo-projects.org/~sofar/byinstallsize.png

Above is correlated by install size (uncompressed size in kB against compile time in seconds), below is correlated against the size of the compressed source code tarballs (same scale).

http://foo-projects.org/~sofar/bysourcesize.png

As you can see there is a faint correlation possible. Most applications install about 10kB of product in 1 second. The other way around you can reason that it takes 1 second to compile 10kB of (compressed) source code. This allows you to pre-estimate the compile time, assuming that your system is the same speed as my reference system.

We can do some more elaborate math on this and calculate the "index" for all modules. The index of a module would be easily calculated by the amount of time it took for lunar to compile and install 10kB of compressed source code. So we divide the total compile/install time (seconds) by the number of kilobytes that the compressed source package was:

gcc took 8025 to compile + install 26952 compressed kB of source code == 3.35
XOrg took 4087 to compile + install 47656 compressed kB of source code == 11.6

If we do this for all modules we end up with the average index of about 27, which means that on average, lunar compiles and installs 27kB of compressed source code per second. Since the size of my /var/spool/lunar is about 1.4gB, it would take me about 51851 seconds to compile and install all of this source code files. That's about 14.5 hours! Of course that number really is not right - we haven't taken into account that larger modules might have a lower index and thus take much longer to compile.

===Indexing modules===

We should be able to index the numbers of all modules right now, so it pays off to pay a closer look at the numbers a bit. Most importantly, the 27 index is averaged across all modules, but we know that this number is off for bigger modules. For modules larger than 100kB source size, it's already 32, and for modules over 1000kB, it's up to 52. This seriously changes perspective and shows you that smaller modules take relatively longer to install, and this is not surprising: the overhead is usually much larger for them, as all the autoconf and administrativa needs to be performed for smaller modules as well.

How long

2005-10-17T07:27:33Z

Sofar: /* Estimating compile time */

How long

2005-10-17T07:26:18Z

Sofar: /* Estimating compile time */

How long

2005-10-17T06:47:41Z

Sofar: properly headerified, adding graphs!

How long

2005-10-17T06:44:50Z

Sofar: Adding correlation graphs

'''''[[how_long]] does it take...'''''
* To install a specific module?
* To install the ISO?
* To recompile all my modules?

These questions get asked a lot by new lunar users and it is a very logical question: Lunar is after all a source distro and requires you to compile all the applications from source, which can sometimes take extremely long!

''''Influencing Factors''''

* ''System(CPU) speed''
Double the CPU MHz, and you double the amount of instructions that a system can make per time unit. So, as a rule, a faster CPU results in faster compiles.

* ''Memory size''
Compiling may require large amounts of memory, especially when compiling C++ applications. Generally, a compilation will go 50% faster if you have double the memory. So, if you only have 128MB of memory, you will speed up your compiles by 225% by increasing the amount of memory to 512MB. This might be worth the trip to the hardware store.

* ''Idle time''
Compiling takes a long time. Every second that your system is doing something else, especially interactive tasks, reduces the amount of time that your system can compile applications.

* ''System architecture and components''
Needless to say that a compile on a SATA hard disk is a lot faster than on a ATA-33 system. Especially with larger modules this is a very important factor.

''''Some basic numbers''''

The following numbers are from a Pentium 4 laptop system with 256 MB, running at 1.8GHz. This is a fairly normal system and if you wish to compare it with your own system, you should keep in mind that this system might be relatively slower or faster based on the influencing factors mentioned earlier.

The modules listed below are very common modules, so they should give you some good insight in how long it takes to compile and install something. Based on the size you can make rough estimates for new modules that you wish to install.

module source size installed size compile time
gcc 27.6 257.3 120:45
XOrg 48.2 93.8 68:07
glibc 13.5 64.7 47:09
gtk+-2 11.8 34.5 26:08
perl 9.8 52.3 17:50

As you clearly can see there is some correlation between installed size and compile time, but there are many outliers in this trend: gtk+-2 comes with a lot of bitmaps and documentation, while the XOrg tarball is counted without documentation. The gcc compiler itself has a very elaborate bootstrap phase that takes almost half the time it takes to compile the target compiler. Many many module-specific factors are at work here.

''''Estimating compile time''''

If you correlate the size of the installed product or the source code size (in compressed form easily available), you get a very loose correlation shown in the graph below:

http://foo-projects.org/~sofar/byinstallsize.png

Above is correlated by install size (uncompressed size in kB against compile time in seconds), below is correlated against the size of the compressed source code tarballs (same scale).

http://foo-projects.org/~sofar/bysourcesize.png

2005-08-11T10:22:53Z

Sofar:

__TOC__

Software raid is a relatively powerful way of achieving better performance and/or reliability (redundancy). There is no automated way of setting this up in lunar yet but it's fairly easy to do manually.

==Getting started==

First setup your box with the number of hard disks you need and boot the ISO. As soon as you boot into the installer and have selected language and locale stuff, switch to vc/2 and start with the manual part of the software raid setup

==Partitioning==

The easiest way to setup partitioning if you're working with partition raid-components is to partition one disc and copy the contents to another using [[cfdisk]] and [[sfdisk]]:

cfdisk /dev/hda

Setup your partitions and make sure you have some space left over for later to resize and move stuff if needed

cd /tmp
sfdisk -d /dev/hda > dump
sfdisk -i /dev/hdb < dump

This formats the second disc identically to the first one, especially usefull for RAID-1 setups

==Setting up your RAID devices==

go to /tmp and create a new raidtab file:

raiddev /dev/md0
raid-level 1
nr-raid-disks 2
nr-spare-disks 0
persistent-superblock 1
chunk-size 32
device /dev/hda1
raid-disk 0
device /dev/hda2
raid-disk 1

Now, since this is sitting on tmpfs you will lose your data if you reboot so be careful. The next step is to initiate the raid device so that it's actively mirroring them (or striping depending on your setup).

mkraid --really-force --config-file /tmp/raidtab /dev/md0

The raid driver will start syncing the discs and you can check progress with:

cat /proc/mdstat

==Formatting the filesystem==

From now on, you'll refer to your disks as /dev/md0 instead of hda1 etc. So the same goes with formatting. You can format and work with the disks even when syncing is in progress:

mkfs.ext3 /dev/md0

It might be a bit slower due to the syncing going on. I advice you to have the unit finish syncing before you reboot, if only to make sure there's no bad sectors on the units and all is OK for normal work.

==Saving your config raidtab==

You should of course save your raidtab file and most likely you will want to save it as /etc/raidtab on the raid-device itself. You'll need to mount it therefore:

mount /dev/hda1 /mnt
mkdir /mnt/etc
cp /tmp/raidtab /mnt/etc/raidtab
umount /mnt

Now you're ready to install lunar in the normal way!

==Installing on RAID==

The last step is to let the normal installer code handle the partitions. For this reason, the installer allows you to pass an arbitrary block device name as an additional hard disk partition. In the partition selection, you select 'Add...' device and enter '/dev/md0'. Make sure you don't format the partition and select the right filesystem. Alternatively, you could have skipped to formatting and let the lunar ISO installer handle it as well.

==BootLoader==

As maybe known, only lilo can directly boot from software raid but with tricks grub can read the underlaying partition on only one of the raid devices, which will obviously not work with striping raid setups. Make sure you pass the proper device names to the lilo.conf. Your mileage may vary.