Hashbang #! and amarok1 on Arch

The #! at the start of bash, ruby, python scripts is called the hashbang. Its use with the Amarok install –

One or two days after writing the article about amarok1 installation on Arch, a new version of amarok1 with ruby1.9 support was uploaded. As most of the ruby scripts for amarok1 still work only with ruby1.8, I decided to keep my old version. Today, while I was looking through a few bash scripts, I realized that using #! in the needed ruby scripts was a better option. So, now I use the  AUR package and just change the hashbang lines in my scripts to point to ruby1.8 exec. If only I had realized this earlier

Anyways, more info about hashbang here.

wget : Add progress bar to non verbose mode

Check this bug report for the problem I had with default mode.

wget has four levels of verbosity which are described as below in its man page –

-d --debug
Turn on debug output, meaning various information important to the developers of Wget if it does not work properly. Your system administrator may have chosen to compile Wget without debug support, in which case -d will not work. Please note that compiling with debug support is always safe---Wget compiled with the debug support will not print any debug info unless requested with -d.

-q --quiet
Turn off Wget's output.

-v --verbose
Turn on verbose output, with all the available data. The default output is verbose.

-nv –no-verbose

Turn off verbose without being completely quiet (use -q for that), which means that error messages and basic information still get
printed.

The problem with these is that the verbose mode prints too much info, quiet prints nothing and non-verbose prints info which is not useful in any way.

Installing Amarok 1.4 on Arch Linux

Installing Amarok 1.4 on Arch Linux is a piece of cake. The package is present on AUR and it has patches for Wikipedia problem, the modified cover fetcher and some others. All you need to do is –

yaourt -S amarok1

and you are done. This will get Amarok 1.4 up and running on your system. But making it work is a bit of a problem. As the binaries are installed in a different directory viz. /opt/amarok/ you will need to add that path to your PATH varible. This will make sure amarok starts without the amarokapp error but the collection scanner does not seem to work. And without a collection there is no way I am going to use amarok. I tried to find various ways around this problem (I had Amarok 2 installed the first time this was done, tried installing without it on the system, adding the /opt/ path at the start of $PATH ) but they did not work so I decided to edit the PKGBUILD file provided on the AUR page. Few of the other problems that I have solved here and my assumptions are mentioned below –

The move to Arch Linux

After using Ubuntu for almost 3 yrs and enjoying it, I have moved to a new distro – Arch Linux. So, instead of my customary short review / first look post after each Ubuntu release, I will be writing a small review / Arch vs Ubuntu post here.

The Why – Well, after using the same distro for about 3 years, I wanted to try something different. With so many distros around, there is hell lotta choice – Debian, Suse, Fedora, Arch etc. I went for Arch coz it has all the things that I was looking for – stability, option to go bleeding edge, a big user community with an active forum, a good package manager and something I have not tried before and coz one of my friends just would not let me rest without trying it . Although, all this might seem stupid , the bottom line is I am now an Arch Linux user.

The Review - How is Arch different from / better or worse than Ubuntu ?

Ubuntu : Install (and remove) all packages needed to build a source code

Ubuntu users (or others who hate Ubuntu) always complain about dependency problems while building something from source. Well, there is a very easy way to solve all those library and other dependency problems. Just use the following ::

$sudo apt-get build-dep <source-package-name>

I have posted this directly from the APT HOWTO . Check it out for a better understanding of APT’s power.

Installing all the build-deps is easy enough but they are (usually) useless once the comilation job is done. So, can they be removed as easily?

There are few options to do this -

• /etc/apt/apt.conf

After this bug was fixed, we now have a option in apt.conf to see if the build deps should be removed when apt-get autmoremove is executed or not. To set them to be removed, add the following to your apt.conf file ( this file is usually not present, create it.)

APT
{
    // Options for apt-get
  Get
  {
     Build-Dep-Automatic "true";
  };
};

Now whatever packages are installed using apt-get build-dep will be removed when you execute apt-get autoremove.

/usr/share/doc/apt/examples/configure-index.gz is a configuration file showing example values for all possible options.

• Command line option

If you want to/don’t want to remove the build-deps of a particular package, pass the following option while using the build-deps command.

sudo apt-get build-dep -o APT::Get::Build-Dep-Automatic=true

True – To be removable by autoremove, False – otherwise.

• If you want to do it after having used build-dep

Well, so far I have been unable to find anything that can reverse the effect after you have already installed the packages. There are some suggestions here and here but I found that they remove cross dependencies as well ( not good )