…or how to purge pulseaudio and systemd presence from your beloved system and start a world crusade in 3 easy steps :) .

This topic arises frequently in all the corners of the world – how to remove even the smallest presence of pulseaudio and systemd from the system. Most Linux-aware people already know that, at least in most modern Linux distribution, there is no need to remove them at all – at least on Mandriva/Mageia-based distributions, both pulseaudio and systemd can be disabled entirely with a click of a mouse (inside draksound, or via ln -sf /etc/sound/profiles/alsa /etc/sound/profiles/current), or with a package removal/replacement (urpmi sysvinit) – but still, I frequently have the chance to met people who are offended by mere presence of said packages and files bearing the smallest similarity to the terms ‘pulse’, ‘audio’, and ‘systemd’ in their list of installed packages in files.

I have to say that I never had any problems with either pulseaudio or systemd for the past years, and I personally consider them as probably one of the most useful items in current generation of Linux distributions – they use most of computer features to provide many different multimedia aspects which otherwise are almost impossible to achieve without hard and tedious scripting and hacking (in case of pulseaudio); and they finally provide a powerful, modern and extremely efficient boot mechanism for Linux distributions (systemd). But.. each one has its own opinion, so who am I to speak for everyone?

So this motivated me to write this post – I’d like to specially thank the people from probably the best Russian open-source-oriented site – opennet.ru – for asking me for doing it. I decided to write it in English however, for 2 reasons:

  1. Those questions arise in each and every language out there, and English is the lingua franca of todays world; and

  2. I write much faster (and probably better :) ) in English than I do in Russian, specially when it comes to technical items and descriptions :) .

So let’s begin. I’ll split this tutorial in 3 big sections – how to find all the traces of pulseaudio and systemd in your system; how to exorcise all the traces of pulseaudio and systemd from all the found packages; and how to make a holy crusade to deliver those packages for the world (we all leave in open-source community after all) :) .

So..

PART I – how to find all the packages which rely on pulseaudio and systemd?

In Mandriva/Mageia and other rpm/urpmi-based systems, a very handy command is urpmf, which allows to search in the repositories for provides, conflicts, files, and so on. In our case, let’s start with pulseaudio, which is considered by The Root Of All Evil on Linux, Unix, and in All The World Under The Sun by some people out there.

To locate all the packages which require pulseaudio stack, let’s search for the packages requiring ‘libpulse’ – this will match packages which require the libpulse.so itself, libpulse-simple.so, libpulse-mainloop-*, and so on. This magical command would be:

# urpmf --requires libpulse

which will output something similar to:

padevchooser:libpulse-browse.so.0()(64bit)
padevchooser:libpulse-mainloop-glib.so.0()(64bit)
padevchooser:libpulse.so.0()(64bit)
lib64alsa-plugins-pulseaudio:libpulse.so.0()(64bit)
lib64mediastreamer1:libpulse.so.0()(64bit)
mplayer:libpulse.so.0()(64bit)
libpulsezeroconf0:libFLAC.so.8
libpulsezeroconf0:libICE.so.6
libpulsezeroconf0:libSM.so.6
libpulsezeroconf0:libX11-xcb.so.1
libpulsezeroconf0:libX11.so.6
...

The output format is: package:requires – e.g., it says for example that mplayer package is requiring libpulse.so.0()(64bit). However, as you can see, it would also list pulseaudio own packages as well (namely, libpulsezeroconf0). So let’s do a different command with some filtering:

# urpmf --requires libpulse | awk -F: '/:libpulse/{print $1}' | sort -u

This will list all the packages available in the repositories which require libpulse pattern.

However, as it is usually the case, not everyone wanting to get rid of pulseaudio wants to remove it completely from the distribution. Most of the time, he just wants to have his small, cozy system to be Truely Free from Lennart’s evil applications (c). So in this case, the following command will compare the results of the previous urpmf command with the list of the installed packages, and print the names of the source rpm files of installed packages which need to be exorcised:

# rpm -q $(urpmf --requires libpulse | awk -F: '/:libpulse/{print $1}' |\
  sort -u) --qf '%{sourcerpm}\n' | grep -v 'not installed' | sort -u

This will pass the urpmf output to ‘rpm -q’ command, asking it to print the names of the source rpm files for each found package, skips the packages which are not installed, and sorts the output removing duplicates. In my case, the list became fairly small, containing only:

alsa-plugins-1.0.24-1.src.rpm
gstreamer0.10-plugins-good-0.10.30-2.src.rpm
kdebase4-runtime-4.6.5-6.src.rpm
kdemultimedia4-4.6.5-2.src.rpm
libcanberra-0.27-3.src.rpm
mplayer-1.0-1.rc4.0.r32713.6.src.rpm
paprefs-0.9.9-8.src.rpm
pavucontrol-0.9.10-8.src.rpm
phonon-4.5.0-4.src.rpm
pulseaudio-0.9.23-1.src.rpm
qemu-0.14.0-1.src.rpm

So, now we have the list of all packages which must be exorcised from the Pulseaudio evil influence! Let’s head for the Systemd-corrupted packages now.

In similar way to what we did to locate packages which need libpulse, let’s do a search for packages which have /lib/systemd files somewhere inside, with a simple:

# urpmf /lib/systemd

Once again, the list is quite bit – and it is a good thing, which means that most of the developers and packagers are adopting the systemd native units already! However, our goal is to remove the evil roots of systemd from such packages, so let’s find out which packages installed on our dear, sweet and comfortable system were possessed by the systemd spirit:

# rpm -q $(urpmf /lib/systemd | awk -F: '/:\/lib\/systemd\//{print $1}' \|
  | sort -u) --qf '%{sourcerpm}\n' | grep -v 'not installed' | sort -u

Once again, the list is quite small (for my machine):

abrt-1.1.14-11.src.rpm
acpid-2.0.10-1.src.rpm
alsa-utils-1.0.24.2-1.src.rpm
avahi-0.6.29-1.src.rpm
consolekit-0.4.5-1.src.rpm
cups-1.4.6-5.src.rpm
dbus-1.4.6-2.src.rpm
initscripts-9.25-5.src.rpm
libcanberra-0.27-3.src.rpm
lm_sensors-3.3.0-5.src.rpm
rsyslog-5.8.2-1.src.rpm
rtkit-0.10-1.src.rpm
smartmontools-5.41-1.src.rpm
systemd-29-3.src.rpm
udev-168-1.src.rpm

But nonetheless, it is quite complete.

So, now we found packages which were tainted by the evil hands of Lennart Poettering (all credits for this phrase belong to opennet.ru), so let’s strip them of this unspeakable evil in the next part!

PART II – exorcising evil beings from innocent packages

Now that we have the list of packages tainted by evil spirits of pulseaudio and systemd, the next step is to remove their dependencies on such entities to make the users who are unable to tame with such unbelievable requirements became happy and in piece with their inner voices!

This section requires a bit of patience and rpm editing skills, so if you lack them probably it will be a bit confusing. In this case, I suggest you to read some references on how to package rpm files (this and this are a nice place to start in case of Mandriva and Mageia distributions).

For the old-school hackers out there, who install src.rpm packages by hand, the initial packaging unpacking is trivial – download the said packages and run rpm -ivh *.src.rpm, and you are done. For the ones who got used to Mandriva/Mageia facilities provided by repsys or mgarepo, the following commands probably would come in handy:

  1. First, we need to find out the name of the package repo – in case of abrt-1.1.14-11.src.rpm it is ‘abrt’, in case of udev-168-1.src.rpm it is ‘udev’, and I’ll let you figure out the remaining ones as an exercise :) .

  2. Second, for each package, we should run repsys co PACKAGE (or mgarepo co PACKAGE).

  3. After that, package with all its sources and specs will become available in PACKAGE directory. So just go there, install the package build requirements, and you are all set.

Now, let’s go to the package exorcism itself. First at all, you have to figure out IF the pulseaudio evil could be stripped from the package during the build process. If it is not possible, well, you have no other solution besides:

  1. Writing your own clone of the package
  2. Writing a patch to the package to not require pulseaudio anymore
  3. Ask upstream developers to remove those functionality from their packages specially for you, out of good will and companionship spirit.

(Somehow I suspect that the 3rd alternative won’t be quite easy in some cases, but one never knows…).

Let’s take for example mplayer package, and use it as example of pulseaudio exorcism. Looking at mplayer.spec file, we cannot find anything which looks like disable this option to disable pulseaudio forever, which is, without any doubts, sad. However, if we take a closer look, there is a %define build_pulse 1 option which definitely looks a bit suspicious. If we change it to %define build_pulse 0, search deeper within the package for the build_pulse flag usage, and add a --disable-pulse option to the build, and rebuild the package with bm -l – then voila! It will build mplayer package without any reference to pulseaudio. Yes, we just had our first package liberated from pulseaudio evil!

In other words, simple patch the package with as follows:

Index: SPECS/mplayer.spec
===================================================================
--- SPECS/mplayer.spec  (revision 691091)
+++ SPECS/mplayer.spec  (working copy)
@@ -56,7 +56,7 @@
 %define build_alsa 1
 %define build_jack 1
 %define build_openal   0
-%define build_pulse    1
+%define build_pulse    0
 %define build_schroedinger 1
 %define build_twolame 0
 %define build_lame 0
@@ -206,6 +206,7 @@


 Name:      %{name}
+Epoch:     9999 # to prevent future upgrades
 Version:   %{version}
 Release:   %{release}%{?extrarelsuffix}
 Summary:   %{Summary}
@@ -630,6 +631,8 @@
 %endif
 %if %build_pulse
        --enable-pulse \
+%else
+   --disable-pulse \
 %endif
 %if !%build_openal
        --disable-openal \

We could check it with rpm -qp --requires RPMS/*/*rpm | grep pulse.

And one important thing comes into mind – how to prevent future upgrades from the distribution to remove all your hard work and changes? One extremely evil, painful and non-rollbackable solution would be to add something like:

Epoch: 9999

into each .spec file. This way, until the distribution reaches this number of package versioning resets, your own packages will take priority above anything distribution says (yes, I told that it would be an evil and extremely hackish solution) :) .

Now it is only necessary to repeat the same process with all other pulse-depending packages. Of course, for some of them (for example, qemu) it is not easy, because pulseaudio support is builtin. In this case, the following options apply – you could either write a patch to remove its support, or ask upstream to build a specific qemu package specially for you without pulseaudio support :) .

As for systemd, the similar strategy applies – with the difference that it would be easier to strip support for systemd in the packages. Just remove all the ‘/lib/systemd’ entries in .spec files, or prepend them with ‘%exclude’ tag, and the support for systemd in said packages will be gone.

In short, resuming this section, if you want to remove pulseaudio and systemd support from your packages, you have to exercise some coding and packaging skills. Unfortunately (for you), most of Linux distributions and environments believe that pulseaudio and systemd are cool and great technologies, so they provide them by default, and it is not very likely that you’ll have any distribution with such changes applied by default… So what could you do now?

The next part explains..

PART III – carrying on a anti-pulse-and-systemd crusade in 2 simple steps

If you want to have any distribution come out without systemd and pulseaudio, you basically have 2 choices.

  1. Make a fork of a distribution, maintain it yourself, and add the packages without pulseaudio/systemd support there. This is the most suitable thing to do if you want to have your own distribution and become rich and famous :) . Alternatively, you have the solution 2. Yet more alternatively, there is always a way to start a brand new distribution yourself.

  2. Create your own repository for packages liberated from pulseaudio and systemd evil influence. This is easier because you don’t need to do the entire distribution on your own, and usually a simple directory on a web-server or ftp would suffice. To follow this path, the following steps should be done:

    2.1. Copy all the resulting packages into a directory

    2.2. Run genhdlist2 directory

    2.3. Put the resulting directory on your http/ftp/rsync server for others to grab it.

This will prepare a Mandriva/Mageia-compatible repository, and when you put it onto a web or ftp server, just share its address with the world, and everyone will be able to add it by running:

# urpmi.addmedia diepulseandsystemd http://your.server.address/repository/$ARCH

This way, on the next urpmi --auto-update run, urpmi will discover that packages from such repo has absolutely higher priority over all possible packages provided by the distribution, and will install them automatically, replacing the currently installed and the available ones. With this, having all the packages freed from the evil pulseaudio and systemd reference, pulseaudio-related packages and libraries will be marked as orphans, and will be removed automatically when you run urpme --auto-orphans.

Therefore, this completes my quick tutorial on how to cleanup the evil presence of pulseaudio and systemd from the packages on a Mandriva/Mageia-based system. Of course, it is possible to improve the packaging, define custom disttags and –with flags for the build, but this text is already becoming too big so I left it out of the scope for now.

So to conclude, I hope you have enjoy reading it as much as I enjoyed this writing :) .

…or, “when you have a hammer, everything looks like a nail”.

Mandriva 2011 beta3 running on macbook air

To do a more fair comparison between Mac and Linux approaches on same hardware, I took a shot and installed Mandriva 2011 beta3 (x86-64 version) alongside Mac OS X on the same Macbook air. The process is nowhere simple nor straight, but it is certainly possible. So in case someone wants to repeat the feat, here is a quick step-by-step instruction how to do so (alternatively, for the impatient ones, you could skip till the end of this post for a simple one-step solution).

  • Download Mandriva 2011b3 from your favorite mirror. The architecture should not matter, but to get the most from the hardware I’d recommend 64bits edition (but it is solely up to you to decide).
  • Run hdiutil convert -format UDRW -o mdv2011.img Mandriva.2011-beta3.x86_64.iso to convert the image to mac-compatible format
  • Now comes the tricky part. In order to make the system boot from this image, it is not enough to create a bootable usb disk or create a local disk partition for the installation. You actually have to create 2 local disk partitions – one where the Linux will be installed, and another roughly equal to the size of the installable image (1.6GB as of mdv2011 beta3), where you should put the copy of the installation image using dd. In other words, you must do the following:
  • Open disk utility from Dock->Utilities.
  • Create a new partition with roughly 2GB in size.
  • Create another partition with the space you want for your Linux install (about 10GB should be enough).
  • Format both partitions as MSDOS FAT.
  • Plug your pendrive which will be used for installation.
  • Open a terminal, become root and run diskutil list, it should show you the partitions you have created and the pendrive. E.g., it should show something like:

  sh-3.2# diskutil list
  /dev/disk0
     #:                       TYPE NAME                    SIZE       IDENTIFIER
     0:      GUID_partition_scheme                        *121.3 GB   disk0
     1:                        EFI                         209.7 MB   disk0s1
     2:                  Apple_HFS Macintosh HD            89.9 GB    disk0s2
     3:       Microsoft Basic Data                         29.2 GB    disk0s3
     4:       Microsoft Basic Data                         2.0 GB     disk0s4
  /dev/disk1
     #:                       TYPE NAME                    SIZE       IDENTIFIER
     0:     FDisk_partition_scheme                        *8.0 GB     disk1
     1:                       0x17                         1.7 GB     disk1s1

Here, disk0s3 is the partition where the Linux system will live after the installation, disk0s4 is the partition for the installer, and disk1 is the disk currently located inside the pendrive.

  • Now we have to transfer the installation image both to the pendrive and local partition. For this, first run diskutil unmountDisk /dev/disk0s4 and diskutil unmountDisk /dev/disk1 to unmount the partitions, and then transfer the image to them with dd if=mdv2011.img of=/dev/disk1 and dd if=mdv2011.img of=/dev/disk0s4.
  • !! AS ALWAYS, make sure you know what you are doing, because dd command does not likes newcomers and non-careful people !!. If you are not careful, this is the step you have the most possibility of losing all your data for good. You’ve been warned.
  • After it is done, the installation procedure is mostly prepared, but you still need to prepare your mac for multi-booting. Luckily for you, this is easy – just install refit and it should work without any configuration.
  • Now, with the pendrive still plugged, reboot your machine. On boot prompt, there will be a new nice refit menu, where you should choose partition tool and allow it to syncronize the GPT partition table with MBR. This is necessary because grub1 and low-level system utilities used in Mandriva 2011 do not support GPT partition tables.
  • Now you can try booting from your pendrive. If you receive a Non-system disk or Unable to find isolinux.bin, make sure that you have followed the steps of having the same image on both pendrive and local partition. What (apparently) happens in this case is that Mac gets confused about the local disks namings (e.g., it confuses the USB partitions with local disk ones), and isolinux gets lost trying to figure what to do and usually gets stuck. There is probably a more clean way to make this work, but as I am lazy sometimes, I just settled with this solution.
  • If you got to the grub splashscreen, congratulations, you have almost reached half of the procedure :) . Now press TAB to edit kernel parameters, and change the root=LIVE:LABEL=… to root=LIVE:/dev/sdb. This way, you are telling kernel that the partition you are booting from is in fact the pendrive, and it won’t get lost trying to solve the puzzle of GPT+MBR+multiple disks mappings (more on this later). Just make sure you select Live system instead of Installation to prevent needless reboots and problems.
  • If everything goes OK, you should be able to boot to KDE with 800×600 resolution. If you reached this point, open the konsole terminal, become root, run draklive-install and proceed with the installation until the partitioning step. At this point, the Mandriva installer gets confused by the GPT+MBR partition table as well, and gets lost about what to do. What you should do is remove the partition you dedicated for Mandriva installation (the big one, not the 2GB one), create a new one with your favorite Linux file system (I suggest ext4) and format it. Just name it as / partition and create no swap – we could always create a swap file later.
  • Now the installer will tell you that the machine must be rebooted to update partition layout and will quit. Instead of rebooting, however, just run partprobe command as root and it will re-sync in-memory partition table with the new disk content, and restart draklive-install. Now it should allow you to proceed with the installation, so just sit back and relax while Mandriva gets installed on your system. Or go make a tea or drink a beer, cause it will take a somewhat long time.
  • When the install finishes, in the bootloader installation step, make sure to install it to the root of the partition – in my case, it was /dev/sda3, but your mileage may vary.
  • The install should finish, but in case grub-install command output in the terminal gave you an error message, you must install grub manually because somehow, surprisingly, it gets confused with the GPT+MBR layout as well. So just run grub-install /dev/sda3 and it should work. If it does not, try running just grub so it would recreate the device mapping, and install the bootloader manually (this is a bit technical and tedious procedure so I’ll skip it on behalf of clarity – feel free to ask in comments if you have questions about this point).
  • Finally, run fdisk /dev/sda, unmark the /dev/sda4 (old installation partition) as active, and mark /dev/sda3 as active. Basically, fdisk /dev/sda – press – a – press – 3 – press -a – press – 4 – w should do it (/me feels like describing Mortal Kombat fatalities with this explanation :) ).
  • Reboot, and a new Linux entry should appear within refit menu. However, when you try to boot it, grub will fail, saying that it is unable to locate kernel and initrd files at correct location. This, once again, is due to mismatch between GPT and MBR partition table, and a quick fix is to change (hd0,3) to (hd0,2) for both kernel and initrd lines. Once again, I am not describing the right fix, but the quickest one.
  • When the system boots, everything should work automatically, including wifi and everything else. As Mandriva 2011 comes pre-loaded with firmware for most closed cards and devices, it all should just work out of the box.
  • Just remember to edit /boot/grub/menu.lst file and make the change from (hd0,3) to (hd0,2) there to have it permanently remembered.

So, that’s it, and if you have got through this quick tutorial to this point and managed to get Mandriva 2011 installed on your Mac machine, you can consider yourself a true geek. Of course, most of this tutorial applies to Macbook Air, because it does not has a CD/DVD port – if it had, most of those steps wouldn’t be necessary at all. But.. we do not seek easy routes, are we? :)

And of course, I mentioned in the beginning of this post that there is a way to install Mandriva on OSX in just 1 simple step. This step is very simple – just ask me to send you a .dd.img copy of my Mandriva partition to you, so you could simple copy it into one of your own partitions, and it will just work. Somehow it feels a more natural way of distributing and packaging anything on Mac platform (I mean, within a .dmg file) – so I am unsure if it is more a hack than the complete tutorial I described above :) .

P.S.: Just to update you with some timings on the same hardware. Mac OS X 10.6.8 takes approximately 10 seconds from refit boot menu towards desktop. Stock Mandriva 2011 beta3 takes approximately 12 seconds from grub menu to kdm, and approximately another 12* seconds from kdm to full-featured desktop. After some optimizations, I could decrease this time to 7 seconds from grub to kdm, and 6 seconds from kdm to full-featured desktop. With auto-login they are tied in this comparison, which is really amazing!

A few weeks ago I finally realized my old wish: I bought a real camera for me: a Nikon D40 – which is, according to many, many people, is the best DSLR out there. At least for non-professionals.

With just a few pictures it was already possible to note the difference – I could not ever EVER got close to those pictures with all my previous cameras (like Nokia N95 and Sony CyberShot W90):

Sunset at Angra dos Reis A flower and a tiny bee Rancho Panorama A beautiful flower

However, after a few days with my new camera, I found out that it came with some dust on its sensor. Not much, but clearly visible on pictures with uniform colors (like sky or white wall). For example, it is possible to see the dust spot on the left half of the following picture – if you zoom in, you’ll clearly see that there is some dark spot covering part of a cloud and appearing in the sky:

A lonely tree among clouds A lonely tree 3

One could say ‘Ahh, but that is just a small tiny spot.. nobody will notice it’. But… I do notice it, and I don’t like it. So I started looking for solutions for this issue.

In first place, I tried cleaning the sensor using a air blower (without luck). The dust spot moved a bit with the air flow (a few microns) and landed to its new place (permanently, I afraid). The next step was to ask the official Nikon support in Brazil, which is located in São Paulo city, about 250km from where I live. Their answer was is that the sensor cleaning should cost around R$ 100 (about 60 US$) + shipping. Quite expensive in my opinion.

So the next step was to start thinking like a computer geek. The photo is digital, so it is nothing more than a bunch of bits :) . So there SHOULD be some software or at least algorithm suitable for cleaning this all. After a quick research, I found that there is the Nikon Capture NX software which removes the dust pretty well. However, it is

  • commercial
  • expensive
  • orders you to take photos in RAW only. I like RAW, but… the memory card is not infinite.

So another option was to clean the dust in gimp. Manually… and it is needless to say that this approach is.. well.. boring, time-consuming and pretty much futile.

However, when all the hope was, apparently, lost, the Great Google Gods sent me a wonderful link to the Resynthesizer plugin – which is AMAZINGLY EFFICIENT in solving the dust issues.

So, dear readers, without other words, I’ll show you the few needed steps to fix the dust on your photos:

  1. Install resynthesizer plugin. On Mandriva systems, you can cheat and run a magic urpmi gimp2-resynthesizer command which will do the trick. On other systems, go to the resynthesizer web site, download, compile and install the plugin. it is trivial, so I won’t go into additional details here.

  2. Grab your dust-damaged image and open it in gimp. As you can see, there is a horrible dust on the left part of the otherwise-blue sky:

Gimp with the dust-cleaning victim

  1. Select a region around the dust to remove:

Selecting the dust to remove

  1. Press CTRL-X to remove the selected area:

Removing the dust

  1. Now, select a bit larger region around the white spot:

Selecting some space around the dust spot

  1. Go to Filters->Map->Resynthesize and run the Resynthesize filter:

The Resynthesizer plugin in all its glory

  1. Wait, wait, and…:

Magic!

  1. That’s it!:

A perfect clear sky!

Of course, it all could be done manually in gimp. However, the Resynthesizer plugin just makes it easier and better.

So what is the result? A bit more magic + some Hugin hacking and…:

Panoramic view of Ilha Bela/SP, Brazil

Yes, that’s right. Every image on panorama had a dust spot, which I cleared up with Resynthesizer. So next time you encounter some dust on your photo, remember that there is a GREAT open-source plugin for gimp out there to help!

Enjoy, and have a Happy New Year! :)

© 2012 Eugeni's blog Suffusion theme by Sayontan Sinha