Five little suggestions for working on GNOME libraries

The GNOME OPW for Summer 2012 is approaching to the end. By working with the code of GUPnP through the internship, I have learned a lot about C programming with GLib/GObject. I think it is a great time to share some from what I learned to everyone, especially the beginners.

Here I collect five small suggestions focusing on coding:

  1. Avoid the trailing white space in your code and patch. Set your editor to be aware of the unnecessary white spaces at the end of line. Git doesn’t like them nor your mentor. If you use Vim, you can look at this page.

  2. Use --enable-shared=no during the configure phase to disable the build of shared library. This makes the test programs under tests directory statically linked to the target library. Otherwise the test programs will be Bash wrapper scripts. Doing so make it easier when you use gdb to load the test programs.

  3. Use CFLAGS=-g in the configure phase to generate the debugging info. Even though you may find configure --help shows you an option called --enable-debug, it basically will convert to -g -O3 for gcc. This -O3 will optimize your code and make it hard to track the execution in gdb.

  4. Combine your local commits into a single patch. After finishing a specific feature or fixing a particular bug, you may have many local commits in your Git commit tree. You may also have merges from the upstream repository. I find this link is extremely helpful to form a single patch from the mess.

  5. Use DevHelp. Even though you might prefer to the online documentation, you should give DevHelp a try. It is more convenient and faster. It can only show the documentation you are interested.

All right. That is it. Hopefully you will find them helpful.

A Recap of Fixing Bug ID 680484

Recently I have fixed the bug 680484 and learned a lot from the process. Therefore I think it deserves a blog post to share my story. The bug 680484 is about a crash when running the program gupnp-dlna-info to dump the input media file’s metadata with -v option. This crash only happens to gupnp-dlna-info linked against gstreamer-1.0. Gstreamer is a comprehensive multimedia processing library. gupnp-dlna, and many other GNOME multimedia packages, depends on it to deal with media files. Nowadays Gstreamer is under the flux from 0.10 to 1.0 (or 0.11) and many GNOME programs are busy with migrating to the Gstreamer-1.0 APIs.

A good introduction to gstreamer-1.0 can be found here. The link also provides the PPA links to install 1.0 on Precise. However I found that the APIs in this PPA slightly fall behind the head of the git. (Update: as of today, Aug 11, 2012, the PPA version is good) So I would recommend to use JhBuild to install the master version of Gstreamer by running jhbuild build gstreamer-master. You probably also need to build gst-plugins-good-master, gst-plugins-bad-master and gst-plugins-poor-master to install the necessary plugins.

To fix the bug 680484 I first verified gupnp-dlna-info had linked to the correct version of gstreamer.

[riko@localhost] tools $ ./gupnp-dlna-info --gst-version
GStreamer Core Library version 0.11.92.1

Now I reproduced the crash by issuing the command like this

[riko@localhost] tools $ ./gupnp-dlna-info ../../../gupnp-dlna-media/strict/audio/NiN_Ghosts_IV_34.mp3 -v

URI:
file:///local/vol00/opw/build/gupnp-dlna/tools/../../../gupnp-dlna-media/strict/audio/NiN_Ghosts_IV_34.mp3
Profile Name: (null)
Profile MIME: (null)

Topology:
  audio: audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)1, layer=(int)3, rate=(int)44100,
  channels=(int)2, parsed=(boolean)true
  Segmentation fault

To make the debugging easier I compiled the gupnp-dlna-info with shared build disabled and ‘-g’ flags to CFLAGS

[riko@localhost] gupnp-dlna $ ../../gupnp-dlna/configure --enable-shared=no CFLAGS='-g'

Next I used cgdb to load the program

cgdb --args ./gupnp-dlna-info ../../../gupnp-dlna-media/strict/audio/NiN_Ghosts_II_12_lo.mp3 -v

In cgdb debugging window I ran the program to make it crash

Now use the command backtrace or bt to retrospect the flow of function calls.

By analyzing the function call history I decided to move the history backwards 4 steps and found a suspicious call.

After referring to the gstreamer-0.10 to 1.0 migration guide, I figured out that the line gst_structure_to_string ((GstStructure *) taglist) was deprecated and I should use gst_tag_list_to_string (taglist) instead. So I verified that in gdb and it seemed to work.

It turned out that was the reason for the crash. Fixed it and the crash was gone.

How to use Rygel to share video and play it back in Totem

In my first OPW progress report I mentioned that I used XBMC player to play back the multimedia files by Rygel. Zeeshan asked if I could use a GNOME DLNA player. Actually I had tried Totem player with Coherence plugin but failed. In the age of GNOME 3, the Coherence plugin is probably obsolete and doesn’t work anymore (no wonder that Totem plugin package in Ubuntu 12.04 didn’t include the Coherence plugin). That was the reason I switched to use non-GNOME apps like XBMC and eezUPnP. But recently I found out there is a GNOME project Grilo that can make Totem work. And I had a feeling that Grilo is gonna replace Coherence as the primary UPnP plugin for Totem. By checking out the git source of Totem, under the plugins directory, there is no more coherence_upnp. Grilo plugin first appeared in Totem 3.2.0 which means that you probably can’t install Grilo plugin for Totem by running ‘apt install’ in Ubuntu 12.04. Therefore I downloaded the latest source release of Totem (3.4.3), compiled and installed it. It ran great on my machine. The following screenshot shows how it looks like:

Use Grilo plugin for Totem to browse the media files shared through Rygel

GNOME OPW Bi-weekly progress report

The past two weeks were very productive. After the first two weeks of take-off stage, I felt much better working on the code. I have gained a great amount of hands-on experiences from networking protocols to code debugging and git use. My major progress was about the library gssdp. Specifically, I have submitted bug 678744 and bug 678660. The bug 678744 was tracked down by using clang. I really like clang‘s colorful outputs and strict syntax check. The bug 678660 is about to use the newly introduced multicast functions in glib-2.32 to replace the gssdp’s own in-house counterparts. The good thing about these new functions is that the support of ipv6. gssdp doesn’t support ipv6 by now, so I hope my work can realize that which evetually will fix another bug.

Another thing worth mentioning is that I noticed that make check would fail if you were running VPN client on your host. For the coming weeks I’m looking forward to fixing more bugs.

GNOME OPW GUPnP Progress Report

Hi everyone,

I would like to write my first progress report on my Gnome OPW project, GUPnP. In the past two weeks, I spent time on getting familiar with the GUPnP project and its sister project Rygel. And I want to share my understanding here.

Different from many other Gnome desktop applications which usually have pretty graphical user interfaces, GUPnP provides the underlying supports behind the stage. It servers as the communication infrastructure for the upper-level applications. It is invisible for the end users but it is a hidden hero.

GUPnP actually consists of several small library projects, e.g. gssdp, gupnp, gupnp-av, gupnp-dlna and gupnp-igd. gssdp (together with libsoup) wraps the network details providing the HTTP-based communication capability such as resource announcement and discovery. gupnp with other gupnp-xxx stuff built upon gssdp implement the UPnP specification. More details can be found on the official website of GUPnP.

Rygel is a media-sever and media-renderer over the home-based network. It is the primary user of GUPnP and heavily based on Gnome/GLib/D-Bus components. To understand what the media-server/renderer/control are and how these things change our digital life, I would recommend to look at the demos at the front page of www.dlna.org. The best way to get the first-hand feel of these concepts is to actually use Rygel or run the test programs in GUPnP source folder.

First, prepare a folder with your favorite songs in it, then run Rygel in the same folder, and then use XBMC player (I recommend) to search the shared songs and play them. So what is the big deal, you may ask. The main idea here is that you can run Rygel in one computer to share your songs, and use XBMC at other computer to play. Imagine that you can also play your songs over the network in your Android/iPhone device too. All right. Do it. You will understand what I’m talking about. Meanwhile I noticed that a good documentation is missing on Rygel website. So I think I can contribute on that even though I’m still a beginner too.

Another thing that really sparked my interest is the use of D-Bus in Rygel. I have known for long that D-Bus techniques have been widely used in GNOME but I have never had a chance to go deep to understand its ins and outs. A nice feature in Rygel is that it exposes its service on a ‘bus’ so that other external programs can connect to this ‘bus’ and use Rygel’s media-sharing capability. At present, I can only scratch the surface without understanding the real story underneath. Hopefully by working the code of GUPnP and Rygel I will do that soon.

All right, summarize my progress. I have to admit the barrier to entry of networking programming is a little high. I finally made some progress on this bug. As what Jens suggested to me, a specific and non-trivial contribution would be to replace the multi-cast socket code in gssdp with the newly available function in GLib-2.32. I’m working on it now. So again, stay tuned. Welcome back to my blog to see what I will have.

Say hi to GNOME!

Welcome to my online garden!

My name is Riko Yamada. I come from Osaka, Japan. I was so excited to be accepted as an intern for GNOME OPW this summer. I will work for the project Rygel and gUPnP. I’m  interested with GTK+/GLib programming. By participating GNOME OPW, I would like to sharpen the skills on the networking programming and get involved in open-source software culture. I will keep sharing my thoughts, lessons and stories collected during my internship. Stay tuned.