Wednesday Dec 17, 2008

How To : Build JDS (GNOME) on OpenSolaris

The second release of OpenSolaris is now officially available 2008.11, and it is a vast improvement over the first release 2008.05. A lot of new hardware drivers have been integrated helping things like audio to just work out of the box.

As OpenSolaris is being targeted at developers it makes sense that you should be able to build the Desktop on OpenSolaris with relative ease. Initially I thought it was going to be difficult but it's actually not, once you follow the following steps.

Bear in mind this is probably not the complete set of steps required and is a work in progess list :), So if you encounter something that I've missed let me know and I will update this blog entry.

1. Install Sun Studio compiler

This can be installed via the ss-dev package.

   $ pfexec pkg install ss-dev

2. Install Required Packages.

Install GNOME development tools package SUNWgnome-common-devel :

   $ pfexec pkg install SUNWgnome-common-devel

Install Perl XML::Parser package SUNWperl-xml-parser :

   $ pfexec pkg install SUNWperl-xml-parser

Install GNU gettext package SUNWgnu-gettext for po procesing :

   $ pfexec pkg install SUNWgnu-gettext

Install GNOME xml documentation packages SUNWgnome-xml\* :

   $ pfexec pkg install SUNWgnome-xml-root
   $ pfexec pkg install SUNWgnome-xml
   $ pfexec pkg install SUNWgnome-xml-share
   $ pfexec pkg install SUNWdoxygen

3. Install docbook catalog.

Once you've installed all the xml stylesheets, you still need to manually update the docbook catalog, this is to ensure xsltproc knows that DTD's are installed locally and it won't try to access the net for DTD's :

   $ pfexec /usr/share/sgml/docbook/docbook-catalog-install.sh

4. Install JDS CBE (Common Build Environment) 1.7+.

Download the CBE from :

   http://dlc.sun.com/osol/jds/downloadds/cbe/test/

Ensure you select the correct architecture. Once downloaded, extract the contents from the tarball.

To install run cbe-install. This needs to be run by a user with Primary Administrator privileges. Users wishing to run and CBE once installed successfully should have at least Software Installation privileges. Privilages are easy enough to add, by either manually editing the /etc/user_attr file or using usermod(1) with the -P CLI option.

NOTE : cbe-install will build and install SVR4 packages.

5. install latest pkgbuild to get IPS support.

CBE 1.7+ includes a version of pkgbuild which at the moment does not generate IPS packages. If you just want to compile packages and generate SVR4 packages then there is no need to perform this step.

Download latest pkgbuild from here :

   http://pkgbuild.sourceforge.net/download.php

Which at time of writing is version 1.3.98. Remove the CBE installed version :

   $ pfexec pkgrm SFpkgbuild

Use the installed CBE to build the downloaded latest pkgbuild package

   $ cd pkgbuild-1.3.98
   $ ./configure --prefix=/opt/dtbld/
   $ make
   $ pfexec make install

6. ACLOCAL

When building some packages you may encounter ACLOCAL build failure messages.

This is caused by aclocal being unable to locate CBE m4 files installed under /opt/dtbld/share/aclocal. By default it looks in /usr/share/aclocal, it also needs to look in /opt/dtbld/share/aclocal.

To fix this ensure the file /usr/share/aclocal/dirlist exists and contains the following :

 
   /usr/sfw/share/aclocal
   /opt/dtbld/share/aclocal

7. JDS Source and spec-files.

In order to build JDS packages you need to download the spec-files that are used by pkgbuild. You can get the latest set of JDS sources from the SVN repository with anonymous access :

   $ svn co svn+ssh://anon@svn.opensolaris.org/svn/jds/spec-files/trunk spec-files-trunk

This will check the trunk version of spec-files into the local directory spec-files-trunk.

Bear in mind trunk is the latest development branch of JDS and some components my not build as they are being currently developed. The GNOME version on !OpenSolaris 2008.11 is 2.24, and the spec-files and JDS sources for this version can be downloaded with anonymous access as follows :

   $ svn co svn+ssh://anon@svn.opensolaris.org/svn/jds/spec-files/branches/gnome-2-24 spec-files-2-24

This will check out the gnome-2-24 branch of spec-files into the local directory spec-files-2-24.

Before you can use _pkgtool_ to build JDS components, you need to ensure manpage tarballs and po-sun tarballs are created. To do this :

   $ cd spec-files-2-24/manpages
   $ make
   $ cd ../po-sun
   $ make

8. Building JDS packages.

You are now ready to build packages for JDS packages using pkgtool. Before using pkgtool or pkgbuild you need to ensure you have the correct environment conifgured, pkgtool comes with two convenience scripts for this very purpose. For csh shell users :

   $ source /opt/dtbld/bin/env.csh

For non csh shell users :

   $ . /opt/dtbld/bin/env.sh

Now pkgtool will be on your path and you can build your spec file :

   $ cd spec-files-2-24
   $ pkgtool --download build-only SUNWblah.spec

At the moment I would recommend using the flag --with-indiana-branding. But this will likely go away in the future.

9. Generating IPS Packages

This will of course build SVR4 packages, if you want to play with IPS you need to use the --ips CLI option for pkgtool. This will build local SVR4 packages, and generate IPS packages from these and by default will populate your local package repository, http://localhost:80/

Before doing this you will of course need to enable your local repository via the smf service pkg/server as follows :

   $ pfexec svcadm enable pkg/server

This will put your local IPS server online http://localhost:80/.

Now you can build your IPS package and have pkgtool populate the local server :

   $ pkgtool --download --ips build-only SUNWblah.spec

10. Installing Your IPS Packages

To actually install and test your local IPS repository and the packages that you have built. Firstly you need to add your local server as an authority :

   $ pfexec pkg set-authority -e -O http://localhost:80/ MyLocalRepo

This will create an authority called MyLocalRepo and enable it. To see what authorities exist :

   $ pkg authority
   AUTHORITY                           URL
   MyLocalRepo                         http://localhost:80/
   opensolaris.org (preferred)         http://pkg.opensolaris.org/dev/

You can see what packages exist in your local repository via Package Manager GUI application or the following command will also list them :

   $ pkg list -a | grep "MyLocalRepo"
or
   $ pkg list -av SUNWblah

If you don't see your package name listed you may need to refresh and indexes :

   $ pfexec pkg refresh --full
   $ pfexec pkg rebuild-index

Before proceeding and installing packages from your local repository it is recommended to take a snapshot of where you are currently at. This will give you the option to rollback to a given point if something goes wrong, ZFS rocks !. Use beadm to create a boot environment snapshot before you install from your local repository :

  $ beadm create -a opensolaris-snap-1

This will create a boot environment snapshot which you can boot from and will return you to a point before you installed anything from your local repo. See beadm man page for more information.

Before installing your packages, if it is already installed on your system but from another authority, probably best to uninstall it first :

   $ pfexec pkg uninstall SUNWblah

To install a package from your local repository you can use the Package Manager GUI application or the following command :

   $ pfexec pkg install pkg://MyLocalRepo/SUNWblah

Summary

So in 8 easy steps you are building desktop packages, in 10 steps you building IPS packages!!

These steps are relatively simple to follow, especially if you are already familiar with using the JDS CBE.

There are plans on making this process really seamless, and provide a meta IPS package, which when installed will simply pull down and install all the required packages in one swoop... it's a work in progress...

Happy building !!!

Tuesday Oct 21, 2008

GNOME 2.24 Session Save & Restore

The latest version of the GNOME Desktop version 2.24.0 contains pretty much a complete rewrite of it's session handling module gnome-session.

One of the features missing from this release is the ability to Save and Restore your session, now bear in mind the session saving and restoring was not completely functional in the first place, applications such as StarOffice, Firefox and Thunderbird all ignore the session management and thus could not be restored via gnome-session.

So how can one get around this, is there a valid workaround ?

Actually there is and it's not that difficult :)

The new gnome-session implements an autostart mechanism for determining what applications are launched for a given session. The autostart mechanism in turn employs .desktop files to define the applications and paramaters etc. You can use gnome-session-propertites capplet maintain the list of applications to be launched for your session.

The default set of autostart files are located under /usr/share/gnome/autostart, for user specific applications .desktop files are located under $HOME/.config/autostart.

You can add specific applications via the preferences capplet gnome-session-properties, which will create the custom .desktop files for your in $HOME/.config/autostart, or you can manually create then .desktop files yourself.

So specifying what applications should be Launched/Restored for your session is quite easy.

The only issue here is that all your apps will appear on the the same workspace (first one), and as for geometry, you would have to rely on the specific application having some CLI for setting X/Y and width/height.

For me this wasn't enough, so I thought how difficult could be be to write a simple shell script that would given some config data, do all this positioning/sizing for me. Turned out to be relatively simple.

So I hacked together two scripts, save-session and restore-session.

Looking at restore-session firstly, it simply reads config data from $HOME/.config/restore-session.conf. This new config file contains a list of name identified applications with location and sizing information. Each line contains TAB separated fields of the following format :

    NAME WORKSPACE X Y WIDTH HEIGHT

e.g.
    #NAME WORKSPACE X Y WIDTH HEIGHT
    GnomeTerminal1 0 397 266 593 719
    GnomeTerminal2 0 1001 266 593 719
    GnomeTerminal3 1 30 30 726 719


Line 1 of the config file is ignored as it just defines column headers, for readability. The NAME column is a single word identification for the specific application. In this example I specify three gnome terminals, two will be located on first workspace (bear in mind workspaces tend to be numbered from 0), and the third terminal located in second workspace.

The restore-session script uses the command line utility wnckprop to get and set information for application windows. This is delivered as part of the SUNWgnome-panel package.

So expanding on the example config file above, for my session I want to restore three terminals with the location and size specified. I now need three .desktop files to start my three terminals on login.

Here's an example for one of them :

    [Desktop Entry]
    Type=Application
    Name=Terminal 1
    Exec=gnome-terminal --title="GnomeTerminal1"
    Icon=utilities-terminal
    Comment=Run a command line shell

Notice how you can specify the title for your terminal via the --title CLI option for gnome-terminal. Just create three of these desktop files and set the titles to be GnomeTerminal1, GnomeTerminal2 and GnomeTerminal3. and place them in $HOME /,config/autostart. The next time you login three terminals will be launched.

Then you ask but this dosen't restore the locations/sizes, there are two methods of doing this part. One would be to create another .desktop file and call the restore-session script directly from it, this however is not reliable as there's no way of guaranteeing the launching order of applications via the autostart method, thus the restore-session could get run before your terminals, and thus will not be able to set their window properties.

The 2nd method is to simply place a launcher on your panel, which runs this script. Again not ideal but still a very simple method to set the properties, you just need to press one launcher each time you login in and presto all your windows get relocated and resized to where you want them.

The 2nd script save-session simply get's the name, size and location properties of all your current application windows and generates a $HOME/.config/restore-session.conf file. This generates config file requires hand editing to set the correct names, but it's a good starting point for generating a $HOME/.config/restore-session.conf file.

Both scripts were written over a few hours one evening so are not perfect, but they do highlight a means of working around the fact that your session is not restored anymore. I'm sure they can be improved. To access the source for the scripts and the example config file just click on any of the links.

About

Install engineer at Oracle who is passionate about Music, Sport and has a soft spot for Solaris

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today