new 32bit chroot image

Just updated and uploaded a new image for use as a 32bit chroot – This is especially for those interesting, who want to use Lunar Linux in 64bit and need to run 32bit apps as well. Lunar Linux is not multilib and will, as it looks like, never be multilib (but never say never, so).

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!

Posted in the daily insanity | Leave a comment

Future use of MAINTAINER= in DETAILS

Currently we aren’t using the MAINTAINER= flag correctly in Lunar. I’d even go that far and say, we don’t care about that flag and we simply ignore it. With the new separation (stable / unstable) this will change:

The maintainer-flag is usually set by developers or people for a specific module; that means such people or developer have a special need or knowledge about that module and should be asked whenever there’s an update or modification to this specific module.

For example:
El_Angelo is set as maintainer for xorg-server, that’s because he’s reading the maillinglists, checking their bugtracker and he knows what he’s doing regarding xorg (At least, thats my impression) – If someone else wants to update xorg-server he/she should ask El_Angelo first why he didn’t update it, yet. Because El_Angelo might have a good reason for not doing so.

That means from now on we will care for the MAINTAINER flag and everytime a module needs a modification or update the MAINTAINER has to be contacted first. If a Maintainer doesn’t respond within two weeks, you can update or modify the module yourself. If it’s _really_ important to update something (bugfix, security patch) you might wait less time; However: Please always try to contact the maintainer, you can assume, that the Maintainer knows better about the module than you do.

We’ve started some sort of mass-mailing to all set MAINTAINER’s in Lunar Linux with a list of the modules they’ve set themselves as MAINTAINER and hope to get a lot of feedback. We will remove all MAINTAINER flags from users who didn’t respond within two weeks.

Posted in the daily insanity | Leave a comment

Lunar Linux: Introducing stable / unstable

Both, developers and users awaited the ability to have Lunar Linux in stable and unstable. The last few days and in the past months we had talks and discussions about that and today we came to a solution.

Instead of writing a lot of bla bla: Currently you can decide between stable and unstable ONLY if you use theedge – And except you’re a developer or know what you’re doing you should NOT play around with it, yet. We’ve started an ongoing process.

We still need to discuss a little bit more on the rules for stable and unstable; However: stable will have older modules (maximum 1month) and will be well tested by developers, where as unstable will contain the latest available stable software (updated frequently) and thus candidates for the stable-branch.

Thanks to all the developers making this possible!

Step 1 – Everything as usual

Step 2 – Whoooa. There’s a new menu item!

Step 3 – Cool. mkay?

Posted in the daily insanity | Leave a comment

Handling renamed modules – An idea

A few days ago we had a little discussion on IRC how to handle renamed modules (once again). Due to the renamed KDE modules a few users had a broken Box because Lunar Linux isn’t keeping track of renamed modules – So, if a module gets renamed it looks like the module got removed and nobody knows how the new module might be called, except he’s searching for that. That leads to a lot of missing modules after an update.
Continue reading

Posted in the daily insanity | 5 Comments

Systemd & Connman

I wrote about a possible switch of the init-system in Lunar Linux some time ago. Today I’ll  show you how to replace your init-system with systemd and connman in Lunar Linux.
Continue reading

Posted in the daily insanity | Leave a comment

Updating old lunar installations: Getting rid of hal

As hal is deprecated now, most new-installations don’t have it anymore. My netbook still has it, so how do I get rid of it easily? Read on, if you want to know..
Continue reading

Posted in the daily insanity | Leave a comment

cache database for moonbase

We’ve had a few talks regarding the use of a database to speed up some processing/end-user-tools. Let’s say “lvu search”, the module searching when issuing “lunar renew” (which should be module_expired() and run_details()). Also things like “lvu depends”. However. Lunar’s package management is as good as it is, because it’s easy. All you need to know is Bash (and not even that correctly). The moonbase (the heart of our package management) resides in /var/lib/lunar/moonbase and contains categories, modules and bash scripts like DETAILS, DEPENDS, PRE_INSTALL just to name a few. Placing all this into a database would make it more difficult to play around with the package management and thats why some people would dislike a database and others would prefer one. And as a result we only talk about it, without doing anything. A year ago (April 2010) I started to work on a cached variant of moonbase, it works by syncing moonbase into a sqlite3 database and optionally using this database instead of the slow file-operations. Yesterday (February 2011) Ratler and I were improving the script I made a lot.
Continue reading

Posted in the daily insanity | Leave a comment