Google Chromium (the open source chrome browser) on Gentoo!

Chromium is not yet complete no matter what I say here. Please do not post bugs or assume this is the final version of chromium. It still lacks a lot of features. My intension here is to only show you how you can get started on building chrome in Gentoo.

Google chromium project has come a long way. I have been building chromium once in a while but it was not stable and was slow until recently. But now I am using it as my primary browser (well there are some exceptions as I will explain later)! It is better than my firefox experience (at least in linux).

To get started head over to this link. First you will need to have all the prerequisites. In ubuntu it is pretty easy. On gentoo we need the gentoo package equivalents of all the prerequisites. Here is the list of things I mapped from ubuntu packages to Gentoo.

* Python >= 2.4 ---> python
* Perl >= 5.x --> perl
* gcc/g++ >= 4.2 --> gcc
* g++-multilib >=4.2 --> ?
* bison >= 2.3 --> bison
* flex >= 2.5.34 --> flex
* gperf >= 3.0.3 --> gperf
* pkg-config >= 0.20 --> pkgconfig
* libnss3-dev >= 3.12 --> nss
* libgconf2-dev --> gconf
* libglib2.0-dev --> glib
* libgtk2.0-dev --> gtk-engines-murrine
* libnspr4-0d >= 4.7.1+1.9-0ubuntu0.8.04.5 --> nspr
* libnspr4-dev >= 4.7.1+1.9-0ubuntu0.8.04.5 --> nspr
* msttcorefonts (Microsoft fonts) --> corefonts
* freetype-dev --> freetype
* libcairo2-dev --> cairo
* libdbus-1-dev --> dbus

The packages I left with a question mark are the ones that I did not how they get mapped on gentoo. Make sure you have installed all the packages with the minimum version required as specified. If you are running 64 bit OS you will probably need to install more packages. See here for 64 bit OS. I was able to build chrome in 64 bit ubuntu following those instructions, so I assume it should be fairly easy to build on 64 bit gentoo. Once you have all the dependencies, it is pretty straight forward.

Get the source code from here. I did not bootstrap from the tarball, because I found the svn checkout easier. But I would suggest that you do use the tarball. It will save a lot of time. Believe me. Following svn instructions, you will need to download depot tools. I downloaded the tools to ~/workspace/c/chrome/chromium/depot_tools. So all the instructions will use that directory.

Next you will need to configure the client and download the code using the following commands.

~/workspace/c/chrome/chromium $ ./depot_tools/gclient config http://src.chromium.org/svn/trunk/src http://chromium-status.appspot.com/lkgr

~/workspace/c/chrome/chromium $ ./depot_tools/gclient sync

This will take a really REALLY REALLY long time. Once you have the code you are ready to build.

~/workspace/c/chrome/chromium $ cd src/build

~/workspace/c/chrome/chromium/src/build $ nice -n 10 ../../depot_tools/hammer --mode=Release app

I niced it a little bit to keep my computer usable for other tasks while it is compiling. The compile will go on for a long time. If everything went without a hitch you will have your chrome browser in ~/workspace/c/chrome/chromium/src/sconsbuild/Release/chrome. Yay! Go ahead take it for a ride. You will be pleasantly surprised to see how much already works.

I ran some chrome experiments to gauge the performance and it is pretty good. Perhaps not as good as on windows, but definitely good. I did not do any firefox to chrome comparisons, so cannot comment much on that. The only downside of chrome browser is that it lacks flash at this point. So no youtube for you. But hey I can use firefox for that. A lot of things still don't work. For example ctrl-alt-t doesn't work. A lot of the options don't still work. Bookmarks have problems, etc. etc.

Here are some screen shots of chromium running in linux.

Installing Boxee on Gentoo: my experience

You have probably heard of Boxee and Gentoo (come on). I wanted to give Boxee a try, because of all the movies and tv shows that I can watch for free. I have already switched from Freevo to xbmc (which is a story in itself) as my primary media center. Since boxee is a fork of xbmc I thought I might give it a try. Why not? Because xbmc was so easy to compile and install. I did not have any problem compiling the latest code from subversion. I registered and downloaded the latest code from Boxee's website. There is no link to svn and so I downloaded version 0.9.11.5591.

The compile was pretty simple
1. Untar the downloaded file
2. autoconf
3. ./configure
4. make -j3

However the compile was not successful. The first problem I ran into was this compile error:

XAPP_MC.cpp:12:20: error: bxcurl.h: No such file or directory

To solve it, I googled around and found the solution in the boxee forums. I had to make minor modifications to the following Makefiles

xbmc/Makefile
SRCS += BoxeeAuthenticator.cpp

xbmc/lib/libPython/Makefile
SRCS += XBPyPersistentThread.cpp

xbmc/app/Makefile
SRCS+= XAPP_Edit.cpp

With the updated makefiles I started the compile process again. Now I got this error message:

*** [Gentoo] sanity check failed! ***
*** libtool.m4 and ltmain.sh have a version mismatch! ***
*** (libtool.m4 = 1.5.26, ltmain.sh = 1.5.2) ***

Please run:

  libtoolize --copy --force

if appropriate, please contact the maintainer of this
package (or your distribution) for help.

make[2]: *** [config.status] Error 1
make[2]: Leaving directory `/home/chandanp/workspace/c/boxee/boxee-0.9.11.5591-src/xbmc/cores/dvdplayer/Codecs/libmad'
make[1]: *** [libmad] Error 2
make[1]: Leaving directory `/home/chandanp/workspace/c/boxee/boxee-0.9.11.5591-src/xbmc/cores/dvdplayer/Codecs'
make: *** [dvdpcodecs] Error 2

Well the solution is in the error message. I issued the following commands:

cd xbmc/cores/dvdplayer/Codecs/libmad/
libtoolize --copy --force
cd -
make

The project compiled successfully. Now to test it. I ran ./Boxee and everything worked beautifully out of the box. I added my boxee account and logged in. Then I could browse all the online content. Sweet! But there is just one problem. I cannot play any of the content I wanted. When I select a video in comedy central the busy circle shows up and it rotates for ever without starting the video. A look at the output showed these errors/warnings:

./bxflplayer-linux: /usr/lib/libcurl.so.4: no version information available (required by ./bxflplayer-linux)
./bxflplayer-linux: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./bxflplayer-linux)

Once again boxee forums to the rescue. The solution that was offered was to copy bxflplayer-linux from an older 0.9.8.4880 release into the latest. So I downloaded 0.9.8.4880 and copied over all the files from boxee-0.9.8.4880/system/players/flashplayer/ to boxee-0.9.11.5591-src/system/players/flashplayer/.

I restarted boxee and couldn't believe my eyes when I saw the videos playing nicely. Watched some clips from comedy central and then turned my attention to the controversial hulu. I clicked on hulu, and everything seemed normal. So I selected a video clip, the player started but I did not hear any audio and the video was just a blank white screen. But the time was ticking as if the media is playing. I did not have my hopes too high anyway and did not expect hulu to work on boxee, what with all the drama. May be there is something subtle that I am missing or may be the old bxflplayer-linux cannot handle hulu's content. No matter what I will keep looking around for some hacks so I can enjoy hulu from boxee.

That is my experience so far with boxee. Oh by the way I had to emerge a lot of packages along the way to make the ./configure work (you can find some dependencies here but it may not be up to date) and also when the bxflplayer could not find some libs (I had to emerge dev-perl/GSSAPI for example). I hate closed source binaries, they are compiled against some libraries and you don't know which libraries are required. Well ldd to the rescue. Still ./configure is the right way.

Update: If you are seeing floating point exception when playing your local media in Boxee then you will need to re-emerge media-libs/alsa-lib" *with* the debug use flag. Here is the discussion from comments regarding this issue:

Blogger VirtualEnder said...
Interesting, well I linked the built, libmad.0.2.1 to libmad.so, then it built just fine. However I'm still having the issue with it crashing any time I try to play anything. I set the log level to 0 and it doesn't even give any errors. It prints to stdout "floating point exception" and that's it. So bizarre. All the internal stuff works fine, as does the music playback, just seems to fuss with videos. mplayer plays the videos fine by itself, no FPE there, so I'm not sure what the problem is, thanks for your suggestions though.

Blogger Chandan Pitta said...
Ah, now that you mention FPE I remember one more hack I had to do (but forgot to mention in the blog), so I am assuming you are in gentoo. If so then you have to "emerge media-libs/alsa-lib" *with* the debug flag. So added this line
media-libs/alsa-lib debug
to /etc/portage/package.use
and re-emerged media-libs/alsa-lib. That should fix your FPE problem. Let me know how it went

How I hacked mplayer to work on Motorola ROKR - Part 2

It has been over a month since part 1, so let me start off quickly and finish this part. I will try to explain how I got the 19 bpp working in mplayer. It was very straight forward really. I had to edit the following files from the mplayer-cvs (you can download the code from http://code.google.com/p/j2me-ctunes/):

libmpcodecs/img_format.c
libmpcodecs/img_format.h
libmpcodecs/vf_scale.c
libvo/osd.c
libvo/osd.h
libvo/vo_fbdev.c
mplayer.c
postproc/yuv2rgb.c
postproc/swscale.c

In libmpcodecs/img_format.c, libmpcodecs/img_format.c and libmpcodecs/vf_scale.c I added a few lines to return something to say 19-bpp is supported in RGB and BGR formats.

libvo/osd.c is interesting. I added a method called vo_draw_alpha_rgb19() which draws the alpha for 19-bpp.

In libvo/vo_fbdev.c, I disabled some code that was causing problems in ROKR and disabled clipping because it was done elsewhere. In addtion added code to initialize variables for 19-bpp format (i.e. r, g, b offsets and lengths. Each color is 6 bits long with 1 bit for alpha) and drawing alpha (using the method previously added in osd.c)

I fixed a few things in mplayer because there was some weird state change after EOF. It did not work correctly on ROKR. I don't remember what was wrong, but for some reason I added a PAUSE state after a file has been played. I used the slave mode of mplayer (see man mplayer for more details about the slave mode) to play media files. So mplayer was always running and when it is time to play a new media file I just pass the new filename from java to the running process that controls the mplayer process. So when a file has completed playing the state of mplayer used to end in PLAYING state. I did not want it to be in that state for some reason so after a play ended I change the state to PAUSE.

postproc/yuv2rgb.c contains the most important hack of all. It is the one that converts YUV data to RGB 19bpp. It was the most fun of all to write the code. Take data point for each pixel in YUV format and convert it to RGB and then fit it in 19 bpp. A lookup table is created up front and the table is used to do the conversions quickly in realtime when the video is playing. I do know much of MMX or SSE extensions (and not sure if ARM supports them) so I had to do all the conversion in C, but it wasn't bad at all performance wise. I got 24 fps for most video formats on a 320 Mhz XScale processor.

The final change is in postproc/swscale.c which converts YUV to packed RGB format.

That is the end of part 2 :). Pretty simple isn't it. Next time I will explain some audio hacks.

How I hacked mplayer to work on Motorola ROKR - Part 1

Ever since I posted the cTunes video on youtube (http://youtube.com/watch?v=coV06ChYWJo), I have been getting a few requests for the app to download and the source code. I have blogged a little about it here and the download link for the app can be found here, here, here and probably a lot more places too. It is wonderful to see an application that I wrote over a few weekends get such wide audience. Forums are still active on this half baked media player.

But people have been asking for the source code and since I moved to a new job and had to shuffle my computers around, I don't remember where the code lives anymore. But the good news is I always have backups as my trusty little cronjob on my ever running PC takes care of backing up all the important files to a 1 TB drive every weekend so I never loose anything. Just hard to find that is all. Wish I had a google search on my .tar.bz2 files ;-). Anyway I took time today to search for the code because a student emailed me asking for the code for her school project where she is allowed to use open source code and modify it for her project. I decided to post the code on code.google.com for the benefit of others who would like to extend the functionality.

There are two parts to the cTunes application. First there is the cTunes j2me application that runs on any media enabled phone (with proper jsrs available of course), and there is a hacked up mplayer I specifically modded to work with rokr e2. I was working at Motorola at the time and knew a little bit of the internals of the phone so it was easy. But this information is nothing difficult to obtain from the net. There are a lot of forums completely dedicated to modding phones, flashing latest images or simply understanding the details.

This is the first of the several installments of how to make ctunes work the way I have shown in the youtube video. First I will start with the mplayer that I built. Please remember that I do not remember all the details of the hacks I did and also the code I used was a very old MPlayer-CVS code from April 2007 or so. First download the code from here and untar it. Now search for

grep -Ri "chandan pitta" *

in mplayer.rokr directory. Those are the hacks I had to do in that version. The hacks may not work with the latest mplayer code. The hack starts with this comment:

// [ modified by Chandan Pitta ]

and ends with this comment:

// [ end modification ]

The rokr e2 has a 32 bit ARM processor and mplayer can be cross-compiled for ARM. So that simplifies the problem a lot for us. However ROKR E2 has a couple of issues
1. The BPP of the phone is 19 and the version of mplayer that I used did not support 19 BPP. So we need a hack for that.
2. The audio driver is motorola proprietary and mplayer does not have a driver. We need a hack to channel audio data to the driver somehow.

I will write another blog explainging how I resolved the 2 issues.

VirtualBox 1.6 is out

The most usable (for me anyway) VirtualBox release for mac is out. I just downloaded 1.6.0 from VirtualBox.org. I was finally able to load the virtualbox additions. Check out my previous blog to read about the issues I faced. Here is a quick recap of the issues:

1. I could not use my full screen real estate which was 1440x900. The max resolution I could get was 1152x864.
   
2. Unable to mount my shared folder.
   
3. Cannot ssh from master OS (mac OS).

First I am glad that VBox for mac has finally come out of beta. Just the fact that there is a release lifts the spirits a bit.

Coming to my first issue, I am now able to make full use of my screen. It did not work out of the box, but the tweaks I had to do were small enough to not make me grumpy.

1. I installed 1.6.0 on my macbook pro.
   
2. Started my Gentoo guest OS.
   
3. Loaded the virtualbox additions iso to the virtual cdrom by doing Devices > Install Guest Additions...
   
4. Mounted the cdrom from Gentoo by doing mount /mnt/cdrom as root.
   
5. Executed /mnt/cdrom/VBoxLinuxAdditions.run. At this point all the modules are compiled and installed. My old /etc/X11/xorg.conf was saved as /etc/X11/xorg.conf.bak and the /etc/X11/xorg.conf was modified to add a new monitor and the video driver was changed from vesa to vboxvideo.
   
6. Restarted my guest OS and all the modules loaded properly (no issues like with the beta release). But my kdm did not start. What gives? So I logged in as root and restarted xdm with /etc/init.d/xdm restart and I got kdm running. It was bizzare that for some reason X failed during boot up. And I know that the only changes were the new video driver and the vbox modules. Since X started normally when I restarted xdm, I knew the the vbox modules did not load before the video driver. What did I do? Just moved the vbox init scipts from default to boot like so
   

   rc-update add vboxadd boot
   rc-update del vboxbox default
   rc-update add vboxadd-timesync boot
   rc-update del vboxadd-timesync default
   rc-update add vboxvfs boot
   rc-update del vboxvfs default
   

   Thats it. Now all the modules get loaded before xdm starts.
   
7. I restarted the guest OS and found out that it did not make full use of screen, but the size is something odd. It just filled the size of the VirtualBox window. So I maximized the virtual box window and restarted, lo and behold my guest OS fills the whole screen. Here is the screen size from xdpyinfo
   

   xdpyinfo | grep dimensions
   dimensions:    1432x830 pixels (378x219 millimeters)
   

8. Sometimes the virtual box does not detect the full screen properly. In such a case just restart the guest OS again in maximized window and it will work.
   

The next issue is mounting the shared folder. With the previous beta release of virtual box the filesystem driver that talks to the shared folder could not be loaded using modprobe. But with 1.6 it has all changed. The vboxsf works! Just do

mount -t vboxsf < shared folder name > < mount point >

and it just works.

The final issue where I cannot connect to the guest OS from master OS still exists and I don't have a solution for that yet. But hey I don't need it now that I have the shared folder working! I can transfer files back and forth between them.

Yet Another GTD now open sourced

I was finally able to clean up the code and add some comments to my pet project YAGTD which stands for Yet another getting things done. See my previous blog for more details. The code is available here if anyone is interested to modify for their specific needs. To try out the application go to http://yagtd.appspot.com/

Elisa problems marshalling MediaUri

The short version
If you are having problems with elisa not playing your local media files (see https://code.fluendo.com/elisa/trac/ticket/957 and https://code.fluendo.com/elisa/trac/ticket/961) then you can fix it by editing ~/.elisa/elisa.conf and changing gstreamer:gst_metadata_client to gstreamer:gst_metadata. That is all and it works!

The long version
Ever since I heard about elisa, I have been trying to get it to work as my media center. It was well designed and the vector graphics are awesome. It plays music, videos and displays pictures, and has several plug-ins to play online music and youtube videos etc. You can even get cover arts from amazon from with in the software. But there is just one problem. It could never play my local media. Neither movies, nor music and not even photos. I gave v0.3.3 of elisa a try. It did not play my personal media. I thought, well it is still in development, so why not wait for the next release. I did not even take a look at the logs.

Then came v0.3.4 and that again did not work. So I synced up to the latest code in svn and tried that. No luck. At this point I was starting to think something must be wrong with my configuration or the versions of dependencies that I have installed. This time I looked at the logs and a warning pointed me to a log file in /tmp. A quick look and I could not understand why jelly.py (from twisted) seems to think MediaUri is not a known type. I didn't know much about twisted framework (and I still don't), so I emailed the elisa mailing list. And in response a developer kindly opened a ticket for me. You can view it here https://code.fluendo.com/elisa/trac/ticket/961.

I was waiting for it to get fixed. And then along came the announcement for v0.3.5. I decided to try the latest from source control and it failed to play my media again. This time I was adamant on learning twisted at least up to the point of understanding what jelly.py is and why it is does not know the type of MediaUri. I found out that jelly is used to serialize data to send it over the wire to the server to unmarshall and act on it. That is good enough. Now back to the exception

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 182, in addCallbacks
    self._runCallbacks()
  File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 307, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "/home/chandanp/workspace/python/fluendo/elisa/elisa-plugins/elisa/plugins/gstreamer_plugin/gst_metadata.py", line 1429, in got_root
    dfr = root.callRemote('get_metadata', dic, low_priority)
  File "/usr/lib/python2.5/site-packages/twisted/spread/pb.py", line 380, in callRemote
    _name, args, kw)
--- <exception caught here> ---
  File "/usr/lib/python2.5/site-packages/twisted/spread/pb.py", line 853, in _sendMessage
    netArgs = self.serialize(args, perspective=perspective, method=message)
  File "/usr/lib/python2.5/site-packages/twisted/spread/pb.py", line 807, in serialize
    return jelly(object, self.security, None, self)
  File "/usr/lib/python2.5/site-packages/twisted/spread/jelly.py", line 879, in jelly
    return _Jellier(taster, persistentStore, invoker).jelly(object)
  File "/usr/lib/python2.5/site-packages/twisted/spread/jelly.py", line 464, in jelly
    sxp.append(self.jelly(item))
  File "/usr/lib/python2.5/site-packages/twisted/spread/jelly.py", line 468, in jelly
    sxp.append([self.jelly(key), self.jelly(val)])
  File "/usr/lib/python2.5/site-packages/twisted/spread/jelly.py", line 489, in jelly
    raise NotImplementedError("Don't know the type: %s" % objType)
<type 'exceptions.NotImplementedError'>: Don't know the type: <class 'elisa.core.media_uri.MediaUri'>

This simply means that there is a problem serializing MediaUri. I greped around and found that MediaUri is not extending one of the serializable classes. So that could be the problem. I looked at the gst_metadata.py which is where the RPC is being made. I noticed that there is another way to get metadata, but it is not an asynchronous call. But hey what the heck, I don't care if the UI locks up for a while when it is scanning my media as long as I can get it to work. So if I used gst_metadata instead of gst_metadata_client I can get away from the whole async RPC calls. I edited ~/.elisa/elisa.conf and changed gstreamer:gst_metadata_client to gstreamer:gst_metadata and guess what, it works!

I updated a ticket with the same problem I was having and at least some one is happy being able to play their local media. The link to the ticket is https://code.fluendo.com/elisa/trac/ticket/957. I got so excited that I wrote this blog immediately. Now I will take elisa for a ride.