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!
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.
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.
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?
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.
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.
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..
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.