The image is Os, i686, mmx, sse and sse2 optimized, which means you’ll need an sse(2) capable CPU to use this image (it’s very likely that you have one if you plan on using such a chroot and if you’re running 64bit, however, you can check using cat /proc/cpuinfo)

The guide and download location is here

My aim for this image was to keep a low amount of pre-installed modules. The image comes with 101 modules:

acl                flex               libtool            psmisc
attr               gawk               libusb             Python
autoconf           gcc                libusb-compat      readline
automake           gccmakedep         Linux-PAM          rsync
bash               gettext            linux-stable       sed
bash_static        glib-2             lunar-init         shadow
bin86              glibc              lunar-tools        sysfsutils
binutils           gmp                m4                 sysvinit
bison              gperf              make               tar
bzip2              grep               modutils-wrappers  texinfo
ccache             gzip               moonbase           theedge
check              installwatch       mpfr               TimeDate
chkconfig          iproute2           nasm               timezone-data
coreutils          iputils            ncurses            udev
cpio               kbd                net-tools          unzip
cracklib           kernel-headers     openssl            usbutils
dialog             kernel-reqs        patch              util-linux
diffutils          kmod               pbzip2             vim
discover           lard               pciutils           wget
discover-data      less               pcre               which
distcc             lftp               perl               wipe
e2fsprogs          libcap             pkgconfig          xz
ethtool            libffi             polylib            zlib
expat              libidn             popt               
file               libmpc             ppl                
findutils          libtirpc           procps             

If you’re using the guide or my image, please let me know, some feedback is always welcome. Have fun!

A Lunar Module (Wikipedia)

Just in case nobody noticed, the Module Site has received a much-needed face-lift, which uses the base template for the main Lunar-Linux website. Some minor changes were also made to improve the overall speed and HTML-correctness since some areas actually had broken markup. The site’s URL scheme was also updated to be more search-engine friendly and proper 404 pages/headers were added where needed. The color scheme and table layout remains, but this may change in the near future as I decide where I would like to go with things. Caching and compression is the next priority, as some dependency pages can take longer than wanted to generate and render.

Beyond that, the wiki and other sites may also receive the same treatment. The screenshots site also leaves a lot to be desired since no work went into the template after the Gallery update, but I am considering migrating it into the main website as a sub-blog. There are various good and bad things about that idea, though. If anyone has ideas, suggestions, grievances, etc. please feel free to share them.

Ever been curious about Lunar’s module statistics? Wonder no more.

1. Retain the basic concepts of the current scripts and improve them to handle additional network connection types. In general just make them better than their current state.
2. Switch to wicd.
3. Switch to NetworkManager
4. Switch to connman

Item one sounds the most appealing since another application would not need adding to the ISO. Well that would be true if only the very basic of network connectivity is desired out of the box such as Ethernet and WiFi. Anything more like VPN and PPPoE will of course need adding to the default ISO. Staying with our own scripts does allow us some flexibility. A good example was a thought by Ratler to move away from the use of ifconfig and friends to iputils.

Wicd has some possibilities. I have used it in the past and for the simple setups I needed, it worked fine. However compared to Item three and four I do not know how well it stacks up with more complicated networks. If their Home page is correct it still does not support PPPoE/DSL.

The NetworkManager has never given me a warm fuzzy. Why I cannot say especially since I have never used it; it is what it is. Perhaps it is in the past I have tried to compile it with the aim of adding it to moonbase. Well there is a show stopper. Color me a newb but I cannot get past this configure error;

Your distribution (lunar linux) is not yet supported!  (patches welcome)

Being the bright newb that I am the most obvious thing to try is this; –with-distro=none or some variant; nope. OK, what about –without-distro; nope. Now this confuses me since Mr. William claims it can be turned off; NetworkManager and ConnMan. Perhaps I am being a dunderhead and not seeing the obvious. Let’s suppose that is not the case and a distro name must be supplied. Let me say it is not like our networking scripts change that often (ahem) but would any dev want to fiddle with sending them patches?

An alternative to maintaining a patch set specifically for them to incorporate we could , shudder, make our  /etc directory structure to fit one of the distros they do support. Some of you should know my position about such things as I have responded to some in IRC. On occasion we get a visitor and in short thrift begins to comment/complain why Lunar does not do $SOMETHING like $DISTRO. I need not comment further.

Now on to connman. Compared to NetworkManager it is less distro dependent and we do not need deal with restructuring /etc to fit some $DISTRO. AFAICT it does support more different types of network connections than wicd.

It seems to me we only have two real choices; rewrite our scripts or connman. On the former it could well be that we would need to restructure /etc in some fashion. That would tend to reduce (though not a lot) the negative I see with NetworkManager.

Image by Adriano Gasparri via Flickr

Hopefully it’s quite obvious that the website has changed just a bit. This is because of our migration over to WordPress from Joomla, which was brought about due to a number of factors:

• Easier to maintain once set up
• Easier to keep updated & migrate to new versions
• Better selection of ready-made themes and plugins

Our site has been rather stale for a time, as we had not seen a fresh post since August, 2010 for the release of 1.6.5 however this was largely due to the main site only being used for news announcements and releases. Since our development team is rather small and the nature of Lunar-Linux’s moonbase of rolling updates without the need of a full release, new articles on the site had been few and far between. To liven things up, we decided it would be nice to have developers or users contribute articles by turning our main site into a “planet” of sorts.

As you will see (or already have), posts will be aggregated from other blogs belonging to our developers and perhaps a few users. The first of which is Jean Bruenn, also known as “wdp” in our IRC channel who is a long-time contributor, mirror provider, and now one of our developers. Jean’s personal blog is where most of his posts originate, along side his own musings.

We are aware of some known issues about the migration. We weren’t able to bring over comments, but there were not many to begin with, so this should not be too much of a concern. Some articles or pages may have formatting issues, but we should be cleaning those up soon. Also of note, some new redirects have been made, some removed, others changed. Should you spot any issues that need our attention, please submit a bug report (yes, the website is on there) and let us know.

Lastly, if you would like your very own blog here, drop us a line on the mailing lists, or via IRC.

However, we still need a solution to handle renamed modules better than we do currently, so I came up with the following snippets:

Patch 1 to /var/lib/lunar/functions/modules.lunar

368a369,381
> # function : module_superseeded
> # usage    : module_superseeded $MODULE
> # purpose  : checks if $MODULE is superseeded by another MODULE
> # return   : returns 0 if superseeded, 255 else
> module_superseeded() {
>   if run_details $1 &>/dev/null ; then
>     if [ ! -z "$SUPERSEEDED" ]; then
>       return 0;
>     fi
>   fi
>   return 255
> }
>
546a560,572
>       fi
>     else
>       # run_details $MODULE worked; thus the module is installed
>       # let's check if it got renamed.
>       if module_superseeded $MODULE ; then
>         message
> "${MODULE_COLOR}$MODULE${DEFAULT_COLOR}${MESSAGE_COLOR} got renamed to
> ${MODULE_COLOR}$SUPERSEEDED${DEFAULT_COLOR}";
>         if query "Do you want to switch to
> ${MODULE_COLOR}$SUPERSEEDED${DEFAULT_COLOR}${MESSAGE_COLOR} ?" y ; then
>           lrm $MODULE
>           lin $SUPERSEEDED
>           continue
>         else
>           message
> "${MODULE_COLOR}$MODULE${DEFAULT_COLOR}${MESSAGE_COLOR} is kept and can
> be renamed manually later${DEFAULT_COLOR}";
>         fi

Patch 2 to /sbin/lin

142a143,146
>           elif module_superseeded $MODULE ; then
>             error_message
> "${LRM_COLOR}Notice:${DEFAULT_COLOR}${MESSAGE_COLOR} The module is
> superseeded by
> ${MODULE_COLOR}$SUPERSEEDED${DEFAULT_COLOR}${MESSAGE_COLOR}";
>             error_message "please lin that one
> instead.${DEFAULT_COLOR}"
>             continue

Remember, the goal was to keep it very simple. The above code changes the way, developers have to handle modules (if they rename them) a little bit. They have to set the SUPERSEEDED flag in DETAILS file to get it working. The devs I talked to have been okay with this approach.

Example:
renamed gcc to wdp-rulez

[lunar] root@lunar /var/lib/lunar/moonbase/compilers # purge_modules
+ Discovering modules that were removed from moonbase
flash-plugin-10 was removed from /var/lib/lunar/moonbase
flash-plugin-10: Do you want to remove flash-plugin-10 ? [y] n
flash-plugin-10 is kept and can be removed manually later
gcc got renamed to wdp-rulez
gcc: Do you want to switch to wdp-rulez ? [y] n
gcc is kept and can be renamed manually later
[lunar] root@lunar /var/lib/lunar/moonbase/compilers #

For devs handling of modules changes to this:

The proper way to handle renamed modules is now:

1. Copy the module to it’s new place and rename the copy.
   e.g: cp -rva compilers/gcc compilers/newgcc
2. Move the old one to zdeprecated
   e.g: mv compilers/gcc zdeprecated/gcc
3. Remove everything _except_ DETAILS from zdeprecated/gcc/*
4. Add: SUPERSEEDED=newgcc to DETAILS
   e.g: echo “SUPERSEEDED=newgcc” >> zdeprecated/gcc/DETAILS

El_Angelo suggested that we make sure that people can’t lin/get
the new module if they “lin” the old one.

Example:

root@lunar ~ # lin gcc
+ Spawning download manager
+ download queue:   gcc
Notice: The module is superseeded by  wdp-rulez
please lin that one instead.
root@lunar ~ #

That way we’re making sure, that nobody installs a package which
is superseeded by another.

Let’s see whether this will go into Lunar