Saturday, June 30, 2012

GNOME 3.6 - clean sheet

Every1 software package builds for GNOME 3.6! Lets hope it stays that way. If you're having some problems, send a mail to the GNOME love mailing list.

JHBuild recently changed the location of the config file. It used to be at ~/.jhbuildrc. It's now at ~/.config/jhbuildrc. JHBuild complies with XDG_CONFIG_HOME, for details see bug 646510. JHBuild will still continue to use the old config if it exists - to not annoy users who setup JHBuild before the switch.

My ~/.config/jhbuildrc contains:

moduleset = ['gnome-apps-3.6', 'gnome-world-3.6']
modules = ['meta-gnome-core', 'meta-gnome-apps-tested']
skip = ['gnome-disk-utility', 'mono', 'gtk-sharp', 'ndesk-dbus', 'ndesk-dbus-glib',
        'mono-addins', 'tomboy', 'pygtk', 'gnome-python', 'gnome-python-desktop',
        'libepc', 'vinagre', 'nemiver']

[1] I do skip some packages, see my ~/.config/jhbuildrc above.

Saturday, December 10, 2011

GNOME 3.4 everything builds except Evolution & Glade

GNOME 3.4 everything builds except:

My ~/.jhbuildrc contains:

moduleset = ['gnome-apps-3.4', 'gnome-world-3.4']
modules = ['meta-gnome-core', 'meta-gnome-apps-tested']

If you're not having the same success, send a mail to the GNOME love mailing list and we'll try to help out!

Thursday, January 6, 2011

GNOME 3.0 builds! And...

After eight months of trying, I am finally able to build GNOME 3.0! Well, apart from:
Neither application is a pivotal part of the GNOME desktop.

Now, does it blend run? No.
Attempting to run gnome-session immediately fails. gnome-session is the application that starts GNOME 3.0.
gnome-session: symbol lookup error:
/opt/gnome/lib64/gtk-3.0/modules/ undefined symbol: gtk_quit_add

This is bug 32839. At quick glance this bug doesn't seem too difficult to work around - remove the offending line of code or roll back GTK+ 3.0 to the parent of 7e7d8c4.

Sunday, December 5, 2010

GTK+ 3.0 gtk-style-context has landed

GTK+ 3.0 gtk-style-context branch has been merged with master. This is an API change that causes a few modules to break in JHBuild:

I created a tracker bug so developers can see how other modules adjust to the API change.

GNOME 3.0 isn't buildable... for now...

Saturday, December 4, 2010

JHBuild moduleset changes

Matthias Clasen rearranged and tidied up the JHBuild modules. If your JHBuild reports an error:
failed to parse gnome-3.0: [Errno 2] No such file or directory: 'gnome-3.0'
An adjustment is required to moduleset within .jhbuildrc. Details within Matthias' blog.

So, does the new gnome-suites-core-3.0 build? No.
  • gnome-packagekit fails, bug 636361
  • tracker fails. It requires dbus >= 1.3.1, but JHBuild has dbus 1.2.24
  • WebKit fails, bug 50451. Subsequently empathy, epiphany and yelp fail.

Tuesday, July 20, 2010

GtkNotebookPage, g_dbus_connection_signal_subscribe migration

The API changes for the gnome-3.0 moduleset keep coming. GtkNotebookPage is no more and a number of modules no longer build. I filed a tracker bug and Frédéric Péters is also auto tracking. glib's GIO g_dbus_connection_signal_subscribe API has changed which is also affecting a number of modules. The change occurred 19-Jul-2010 (yesterday) in commit 4a1c5a1b. I did some searches - no bugs exist for this migration yet.

Sunday, July 4, 2010

GdkRegion migration

The GDBusProxy problems I blogged about were fixed quickly thanks to the hard work by Carlos Garcia Campos, Matthias Clasen and others. The GDBusProxy API changes are stable, see 'API changes in GLib master' by Matthias Clasen.

The gnome-3.0 module set is moving to GTK+ 3, and so begins the next round of build failures. GTK+ 3 has removed GdkRegion, to be replaced by Cairo's cairo_region_t. Software that hasn't migrated fails to build: metacity, gucharmap and gnome-control-center. A few modules depend on metacity and gnome-control-center so I can't test GNOME for now.

Thursday, June 17, 2010

GDBusProxy migration

I am building GNOME with JHBuild using the gnome-3.0 module set. gnome-panel, nautilus and evince are failing to build due to an API change in glib's gio. glib's API change occurred in commit 32f2e9. I raised bugs for each module and linked them to a tracker bug. Is the new GDBusProxy API stable? If yes, API migration is a good way to get started in GNOME development. Not too difficult and appreciated by the developers.

If you too are building and testing GNOME 3.0 there may be some fun ahead!

Tuesday, June 8, 2010

JHBuild and .jhbuildrc

I am building GNOME using JHBuild. I've set-up a .jhbuildrc as per the manual. Here is my .jhbuildrc. It shows how I use JHBuild and how I work around some problems.

I am attempting to build the next development version, GNOME 3.0.
moduleset = ['gnome-3.0']

I checkout and build the sources within the gnome2 directory.
checkoutroot = os.path.expanduser('~/gnome2')

I build using 'jhbuild tinderbox'. With the following setting, all build output will be stored within the output directory. I then browse the results in a web browser starting at ~/output/index.html. With tinderbox output, I can easily copy and paste output into bug reports.
tinderbox_outputdir = os.path.expanduser('~/output')

I set nopoison. I don't want an erroneous commit to stop my build. The dependent packages will use the last JHBuild installed version. If there is no installed version, the package will fail but that's ok.
nopoison = True

I adjust and make fixes to the moduleset files. Ask JHBuild to use local modulessets.
use_local_modulesets = True

This causes verbose output when building. This allows me to see if CFLAGS or other environment variables that may cause the build to fail.

Install GNOME to /opt/gnome2
prefix = '/opt/gnome2'

Turn off compiler optimisation with -O0. It makes debugging easier. Sometimes with high optimisation settings, the current executed line jumps about in unexpected ways. Also enable debug symbols with -g.
os.environ['CFLAGS'] = '-O0 -g'

After a successful build, there will be two versions of libraries on my system. The distribution provided libraries in /usr and JHBuild libraries in /opt/gnome2. Two common ways to set which libraries to use are:
  1. LD_LIBRARY_PATH. Set the environment variable LD_LIBRARY_PATH. JHBuild sets LD_LIBRARY_PATH automatically when building and for the 'jhbuild shell' and 'jhbuild run' commands.
  2. rpath. With the rpath setting, the library path at /opt/gnome2 is hardcoded into executables. As JHBuild sets LD_LIBRARY_PATH, rpath isn't necessary but I use rpath to ensure the right libraries are used regardless of the environment. Sometimes I start executables from the debugger or via gnome-session so managing LD_LIBRARY_PATH isn't always simple.
os.environ['LDFLAGS'] = '-Wl,-rpath -Wl,' + prefix + '/lib64'

I don't build the documentation to speed up the build a little bit. I enable introspection as it is becoming an important part of GNOME 3.0 and language bindings.
autogenargs='--disable-static --disable-gtk-doc --disable-documentation ' + \
            '--disable-docs --enable-introspection'

The modules I don't build. I don't build Mozilla because GNOME is moving towards WebKit. I don't build mono as it's only used by Tomboy and I like gnote much better. I don't build nss nor nspr as they are a big pain - bug596385, bug618499, bug619000 etc. I use the distribution versions - package nspr-devel and nss-devel on Fedora. I don't build UPower, hal, polkit, PolicyKit, DeviceKit because they are system-level components. JHBuild versions won't work according to bug581515.
skip = ['mozilla', 'mono', 'gtk-sharp', 'gnome-sharp', 'gnome-desktop-sharp'
       'samba4', 'libmapi', 'evolution-mapi', 'ndesk-dbus',
       'mono-addins', 'tomboy', 'sabayon', 'gnome-desktop-sharp', 'ptlib', 
       'opal', 'ekiga', 'evolution-exchange', 
       'gdm', 'libgnomecups', 'nspr', 'nss',
       'gtk-vnc', 'vinagre',
       'speex', 'libsndfile', 'pulseaudio',
       'UPower', 'libvolume_id', 'hal', 'polkit', 'PolicyKit',

My module autogen arguments. Important ones are gtk+ with --with-xinput=yes. Some modules will not compile if gtk+ is built without xinput. The LDFLAGS=-ldl should no longer be necessary due to the fixed bug620741. OpenGL modules need args for /usr/include/nvidia and /usr/lib64/nvidia for my Nvidia based Fedora system.
module_autogenargs['clutter'] = 'CPPFLAGS=-I/usr/include/nvidia ' + \
 'LDFLAGS=-L/usr/lib64/nvidia ' + autogenargs
module_autogenargs['clutter-gtk'] = 'CPPFLAGS=-I/usr/include/nvidia ' + \
 'LDFLAGS=-L/usr/lib64/nvidia ' + autogenargs
module_autogenargs['dbus'] = autogenargs + \
 ' --with-dbus-user=dbus --enable-verbose-mode'
module_autogenargs['ekiga'] = autogenargs + ' --disable-ldap'
module_autogenargs['empathy'] = 'CPPFLAGS=-I/usr/include/nvidia ' + \
 'LDFLAGS=-L/usr/lib64/nvidia ' + autogenargs
module_autogenargs['evolution'] = autogenargs + \
 ' --disable-nm --disable-exchange --disable-pst-import'
module_autogenargs['gnome-games'] = 'CPPFLAGS=-I/usr/include/nvidia ' + \
 'LDFLAGS=-L/usr/lib64/nvidia ' + autogenargs + \
 ' --disable-tests ' + \
        ' --enable-omitgames=aisleriot'
module_autogenargs['gtk+'] = autogenargs + ' --with-xinput=yes'
module_autogenargs['libcanberra'] = autogenargs + ' --disable-oss'
module_autogenargs['libchamplain'] = 'CPPFLAGS=-I/usr/include/nvidia ' + \
 'LDFLAGS=-L/usr/lib64/nvidia ' + autogenargs
module_autogenargs['libsndfile'] = 'LDFLAGS=-ldl ' + autogenargs
module_autogenargs['NetworkManager'] = autogenargs + \
 ' --with-dbus-sys-dir=' + prefix + '/etc/dbus-1/system.d' + \
 ' --with-udev-dir=' + prefix + '/lib/udev'
module_autogenargs['PackageKit'] = autogenargs + ' --enable-yum'
module_autogenargs['ptlib'] = autogenargs + ' --enable-samples'
module_autogenargs['sqlite3'] = 'LDFLAGS=-ldl ' + autogenargs
module_autogenargs['tracker'] = autogenargs + \
 ' --enable-evolution-miner=no '

Suggestions or improvements welcome.

Saturday, June 5, 2010

How to start GNOME development? The website does not make it easy

Welcome to GNOME developer blog. This blog details my journey starting out as a GNOME developer.

I use GNOME and I've decided I wish to contribute. I want to contribute as a developer. The steps I usually take when developing software are:
  1. Download
  2. Build
  3. Run
  4. Learn
  5. Edit
For GNOME getting to step 1 is not easy.

Where to start? I decide is a good place to start. A 'Contribute' link is easy to find. Good work GNOME team.

The 'Contribute' link takes me to a community page. I don't like this page. The page writes about news, reviews and user groups. I want to contribute code. Eventually I find what I am after. At the very bottom of the page is a start contributing link.

Now I am at the 'Joining the GNOME Project...' page. The page layout is clear. I was able to quickly discover the correct section - Development. I followed the GnomeLove link.

I visit the 'Getting started' section. 'How to Start Your GNOME journey' sounds exactly what I want. This page suggests submitting bug fixes. How do I test fix or test bugs before building GNOME? The page doesn't mention building GNOME.

'Technical guides' seems promising - it mentions a guide on building. Alas, the guide is out of date. It details CVS which is no longer used and refers to GNOME servers that don't exist. However the guide indicates JHBuild may be what I am after.

Now I know about JHBuild, I find the JHbuild page. I set-up JHBuild and my GNOME development journey is away. That was too hard. Some developers may already be frustrated. Instructions on how to build GNOME should be more prominent on the GNOME website - not buried five steps below a Contribute link.