Friday 4 September 2009

How To : Use Distro Constructor To Add Custom Slim Install Packages

This is a Quick 'n' Dirty guide to creating an LiveCD ISO image for OpenSolaris on OpenSolaris.

NOTE: these notes are written assuming you have access to Sun's internal servers. You may be able to populate your own local IPS repo from some other source, I don't know how off hand but if you find out let me know and I'll add that info here aswell.

1. Some Environment setup

Install ss-dev and SUNWonbld packages, this will ensure all required dev tools are installed such as SunStudioExpress and create SUNWspro symbolic link :
  $ pfexec pkg install ss-dev SUNWonbld
  $ pfexec ln -s /opt/SunStudioExpress /opt/SUNWspro
Some other dependencies that I also installed were :
  $ pfexec pkg install SUNWgnome-common-devel
  $ pfexec pkg install SUNWpython-setuptools
  $ pfexec pkg install SUNWpython-pycurl
If the build fails, see what the build was looking for and use pkg search filename to see what other package might be necessary.
Ensure your PATH has SunStudioExpress and onbld included, and also has /usr/bin before /usr/gnu/bin :
  $ export PATH=/usr/bin:/opt/SunStudioExpress/bin:/opt/onbld/bin:$PATH

2. Create local IPS Repository

First clone the gate (IPS) source and build/install it :
  $ cd
  $ hg clone ssh://anon@hg.opensolaris.org/hg/pkg/gate
  $ cd ~/gate/src
  $ pfexec dmake packages
All gate related packages are available under : ~/gate/packages/i386.
On OpenSolaris, just enure you have the most up to date versions of these package installed from your default authority :
  $ pfexec pkg install SUNWipkg SUNWipkg-brand SUNWipkg-gui SUNWipkg-gui-data  SUNWipkg-gui-l10n SUNWipkg-um SUNWpython-cherrypy SUNWpython-mako SUNWpython-ply SUNWpython-pycurl
On SXDE you should remove the old versions of these packages and install the newly built ones. Before installing these packages ensure the pkg/server SMF service is disabled.
  $ svcs -a | grep pkg/server
  online         Feb_18   svc:/application/pkg/server:default
If online then disable :
  $ pfexec svcadm disable pkg/server
  $ svcs -a | grep pkg/server:default
  disabled       11:26:58 svc:/application/pkg/server:default
Now as root :
    $ pkgrm SUNWipkg
    $ cd ~gate/packages/i386
    $ ls
    SUNWipkg               SUNWipkg-gui           SUNWipkg-gui-l10n
    SUNWpython-cherrypy    SUNWpython-ply         pkg5-c700981b0af2.pkg
    SUNWipkg-brand         SUNWipkg-gui-data      SUNWipkg-um
    SUNWpython-mako        SUNWpython-pycurl      pkg5.pkg
    $ pkgadd -d pkg5.pkg
    $ pkginfo SUNWipkg

3. Set up Local IPS Repository.

By default pkg/server uses /var/pkg/repo for it's package directory. If you choose to use the default the first time you import just ensure it's contents are clear out :
  $ svcadm disable pkg/server
  $ pfexec rm -rf /var/pkg/repo/*
Best practice though would be to create a new zfs location for local repo:
  $ pfexec zfs create rpool/ips
  $ pfexec zfs create rpool/ips/repo
  $ pfexec zfs set mountpoint=/export/ips/repo rpool/ips/repo
If you do create a new directory you need to set the pkg/inst_root property of the SMF service to point to this new location :
  $ pfexec svccfg -s pkg/server setprop pkg/inst_root = /export/ips/repo
You need to update the default port number from 80 to 10000, 10000 is the port used by distro-import :
  $ pfexec svccfg -s pkg/server setprop pkg/port = 10000
Refresh and enable pkg/server, and check your settings :
  $ pfexec scvadm refresh pkg/server
  $ pfexec svcadm enable pkg/server
  $ svcprop pkg/server | grep port
  pkg/port count 10000
  $ svcprop pkg/server | grep inst_root
  /export/ips/repo (or /var/pkg/repo)
You can browse the repo in browser with following URL :
     http://localhost:10000

4. Create your own slim install packages.

Get the sources:
  $ cd
  $ hg clone ssh://anon@hg.opensolaris.org/hg/caiman/slim_source
Read ~/slim_source/usr/src/README and follow the instructions on how to build.
You need five other packages of which 4 are not on the IPS servers but are available on http://dlc.sun.com/downloads. These are SUNWzoneint, SUNWwbint, SUNWldskint, SUNWinstallint and SUNWswig. Just download and install them using pkgadd. The following shows a single line command that will download and install in one go :
  $ pfexec pkgadd -d http://dlc.sun.com/osol/install/downloads/current/SUNWldskint.`uname -p`.pkg all
  $ pfexec pkgadd -d http://dlc.sun.com/osol/install/downloads/current/SUNWwbint.`uname -p`.pkg all
  $ pfexec pkgadd -d http://dlc.sun.com/osol/install/downloads/current/SUNWzoneint.`uname -p`.pkg all
  $ pfexec pkgadd -d http://dlc.sun.com/osol/install/downloads/current/SUNWinstallint.`uname -p`.pkg all
  $ pfexec pkg install SUNWswig
Before you build if you have pulled your slim source to a location other than the default "slim_source", you need modify developer.sh and change CODEMGR_WS to point to this location. To build your packages just :
  $ cd ~/slim_source/usr/src
  $ ./nightly developer.sh
This will build packages under : ~/slim_source/packages/i386/nightly-nd, and the nightly build log is located in ../../log/*/nightly.log.

5. Import packages to local Repo.

Now that we have some custom packages we want to generate a local repo which will contain latest nevada and your custom packages. To import latest nevada packages to your local IPS repo you need access to Sun internal servers. You can edit the Makefile located at :
    ~/gate/src/util/distro-import/Makefile
And set the following variables :
Name Description Value
WOS_PKGS preferred internal repository, I use the default WOS_PKGS=/net/netinstall.sfbay/export/nv/x/$(BUILDID)/Solaris_11/Product
REPO set to your local IPS repository that you are importing to. REPO=http://localhost:10000
NONWOS_PKGS Set this to the location of your distro specific packages, these include IPS and Caiman Install packages. I just leave it as the default : NONWOS_PKGS=/net/paradise.sfbay/export/integrate_dock/nv/$(NONWOS_DOCK)/all /net/paradise.sfbay/export/integrate_dock/nv/$(NONWOS_DOCK)/$(ARCH)
TEST_PKGS Set this to the location of your custom packages you want in the repo. Default is blank : TEST_PKGS=
NOTE : If you don't have any custom packages leave TEST_PKGS blank.
Save and exit the Makefile. The following manifest file can be used to initialize your pkg/server service back to default values. Before importing you should edit the file and ensure the pkg/inst_root and pkg/port are assigned the correct values e.g. /export/ips/repo and 10000 :
  $ cd ~/gate/src/svc
  $ pfexec svcadm disable pkg/server
  $ pfexec svccfg import pkg-server.xml
  $ pfexec svcadm refresh pkg/server
  $ pfexec svcadm enable pkg/server
Change directory back into  distro-import, and using a the specific build number use redist_import script to populate your local IPS repo. e.g. for build 121 :
  $ cd ~/gate/src/util/distro-import
  $ make 121/redist_import
NOTE:This will fail if you have the JDS CBE included on your PATH, e.g. ensure
/opt/dtbld/bin is NOT included in your PATH.
This step can take quite a while. In your browser, keep an eye on http://localhost:10000 — it starts get new packages after a while.
After an initial import to your local IPS repo, if you created a new zfs filesystem for your local repo, it's best to create a snapshot at this time, this will allow you to return to a clean initial repo without haveing to re-import everything again :
  $ pfexec zfs snapshot rpool/ips/repo@virgin
To roolback to this snapshot at a later time you can run the following :
  $ pfexec zfs rollback rpool/ips/repo@virgin
There are some alternative imports which can be run but they have caveats:
make 121/redist_import will pull in all redistributable packages and make the entire package
make 121/slim_import will pull in just slim (install) packages
make 121/redist_import -j will pull in just the command-line listed packages

6. Install or Push local test packages into your local repo.

There are a number of methods that can be used to push some custom packages into your local repo.
  • 1. Use solaris.py to push into your local repo
    To push custom SUNWgui-install into http://localhost:10000 repo :

      $ cd ~/gate/src/util/distro-import/
      $ mkdir gui-install
      $ cat > gui-install/SUNWgui-install << EOF
      > package SUNWgui-install
      > import SUNWgui-install
      > end package
      > EOF
    The above script may also contain other commands if required such as adding users/groups which might be required by specific packages. See ~/gate/src/utils/distro-import/105/common/SUNWslim-utils as an example of how to create a user. Now create a metafile pointing to the gui-install stuff :

      $ cd ~/gate/src/util/distro-import/
      $ cat > gui-install.list << EOF
      > include gui-install/SUNWgui-install
      > EOF
    Finally run solaris.py to push the SUNWslim-utils package into the repo :

      $ ./solaris.py -b 6.6 -d -s http://localhost:10000 -w ~/slim_source/packages/i386/nightly-nd slim-utils.list
    Pay attention to the above. The "-b 6.6" specifies the revision. You just bump it up higher and higher to make sure that version is found. The ~/slim_source/packages/i386/nightly-nd is the directory containing the packages.
    You can verify that the right version was pushed with the following :

      $ pkg image-create -F -a test=http://localhost:10000 /tmp/test-image
      $ pkg -R /tmp/test-image install SUNWgui-install
      DOWNLOAD                                  PKGS       FILES    XFER (MB)
      Completed                                  1/1       30/30      0.0/0.0
      PHASE                                        ACTIONS
      Install Phase                                  58/58
      PHASE                                          ITEMS
      Reading Existing Index                           8/8
      Indexing Packages                                1/1
      $ pkg -R /tmp/test-image list -av SUNWgui-install
      FMRI                                                           STATE      UFIX
      pkg:/SUNWgui-install@0.5.11,5.11-6.6:20090219T082311Z           installed  ----
    Note the -6.6 at the end of the version shown in the list above.
    In order for distro_const to include the correct version of your custom package in the ISO, the package entire needs to be rebuilt so that it's manifest includes your package version.
    To achieve this firstly go back to your IPS gate source and edit Makefile :

      $ cd ~/gate/src/util/distro-import
      $ vi Makefile
    Edit the Makefile, and comment out the recreation of entire.incorporation, by changing line :

          From : entire: $(BUILDID)/entire.incorporation
          To   : entire: #$(BUILDID)/entire.incorporation
    Now edit the specific build entire.incorporation file :

      $ vi 121/entire.incorporation
    and change the version of the package listed here to your local version e.g. for SUNWgui-install :

          From : depend fmri=SUNWgui-install@0.5.11-0.121 type=incorporate
          To   : depend fmri=SUNWgui-install@0.5.11-6.6 type=incorporate
    Now re-build the entire package :

      $ make 121/entire
      PKG_REPO=http://localhost:10000 ./import_manifest_file \
          entire@0.5.11,5.11-0.`echo 121 | tr -d '[a-z]'` \
          121/entire.incorporation
      PUBLISHED
      pkg:/entire@0.5.11,5.11-0.121:20090903T143856Z
    Do a quick restart of the pkg/server, even though I'm not sure it's definitely required. Now check http://localhost:10000, search for package entire, once found click the "manifest" link and browse down to your custom package, the version listed here should be the one you published.
  • 2. Import at initial local repo creation time
    When your first populate your local IPS repo you could set TEST_PKGS as stated in the section above to point to the location of your custom SVR4 packages, it will automatically grab all packages here and install them in your local repo.
  • 3. Re-run redist_import to re-populate your local repo.
    Quite similar to previous method, except in this case you already have a populated local repo, you can re-run redist_repo to re-populate your local IPS repo. Before doing so you can set the environment variable TEST_PKGS to point to your custom packages :

      $ export TEST_PKGS=~/slim_source/packages/i386/nightly-nd
    Then re-run redist_import specifying -e make flag to override environment variables in the Makefile from current shell environment:

      $ cd ~/gate/src/util/distro_import
      $ /usr/bin/make -e 122/redist_import
NOTE:Options 2 & 3 above can take quite a bit of time depending on network connectivity and hardware specification.

7. Build Distribution ISO.

NOTE:If you have run disto_const on a build of OpenSolaris prior to snv_129, I would recommend that you destroy the default zfs distro constructor datasets. distro_const will recreate these when run again. One of the possible errors you may encounter is an error where distro_const cannot find directory boot_archive, this is because bootroot was renamed to boot_archive. To destroy run the following commands :
  $ pfexec zfs destroy -r rpool/dc
Ensure SUNWdistro-const is installed :
  $ pfexec pkg install SUNWdistro-const
Now make a copy of the distro XML manifest that you want to use to generate the ISO :
  $ mkdir ~/mydistro
  $ cp /usr/share/distro_const/slim_cd/all_lang_slim_cd_x86.xml ~/mydistro/mydistro.xml
  $ cd ~/mydistro
Now edit ~/mydistro/mydistro.xml :
  • Change the distribution name to one of your choice :

         From : <distribution name="OpenSolaris">
         To   : <distribution name="MyDistro">
  • Change url element of <pkg_repo_default_authority> section from :

          From : pkg.opensolaris.org/release
          To   : localhost:10000
  • Change authname element of <pkg_repo_default_authority> section from :

          From : opensolaris.org
          To   : myrepo
  • Optional to remove generation of usb image.
    If you don't want the distro.usb image to be generated then comment out or remove the usb finalizer script from within mydistro.xml. Go to section <finalizer> section and remove/comment out the following <finalizer> section :

       <script name="/usr/share/distro_const/create_usb">
          <checkpoint
             name="usb"
             message="USB image creation"/>
       </script>
  • If you are using a custom finalizer script to pkgadd custom packages as detailed in the last section below, ensure the required changes are made to the <finalizer> section.
Now run distro_const on this mydistro.xml file to generate your ISO :
  $ pfexec distro_const build ~/mydistro/mydistro.xml
By default this will generate an installation under ZFS dataset :
    rpool/dc
If this filesystem does not exist it will be created. The media once generated will exist in :
    /rpool/dc/media

8. Test Your LiveCD ISO Using VirtualBox.

Boot from /rpool/dc/media/MyDistro.iso.

9. Use of Custom Finalizer script to install custom packages.

An alternative to pushing custom packages into your local repo, and regenerateing the entire package, you could simply use a finalizer script to add these packages to distro_const's default pkg_image area when it is creating the image.
When distro_const is run to create your distro, a number of finalizer scripts are run for the various steps to generate the distribution ISO image. These scripts are defined in the &lt'finalizer> section within the xml manifest used by distro_const. e.g. mydistro.xml mentioned above.
You can add your own finalizer script to pkgadd your custom packages to the image install area before the distro itself is constructed. The first script is "pre_bootroot_pkg_image_mod", add your custom finalizer install script just after this and just before the "slimcd_pre_bootroot_pkg_image_mod" script. It might look like the following :
   <script name="~/mydistro/add-custom-pkgs">
      <checkpoint
         name="add-custom-pkgs"
         message="Add Custom pkgs"/>
   </script>
The script add-custom-pkgs might contain the following :
  $ cat ~/mydistro/add-custom-pkgs
  #!/usr/bin/ksh93

  ADMIN_FILE=/tmp/admin.$$
  cat << \ADMIN_EOF > $ADMIN_FILE
  mail=
  instance=unique
  partial=nocheck
  runlevel=nocheck
  idepend=nocheck
  rdepend=nocheck
  space=nocheck
  setuid=nocheck
  conflict=nocheck
  action=nocheck
  networktimeout=60
  networkretries=3
  authentication=quit
  keystore=/var/sadm/security
  proxy=
  basedir=default
  ADMIN_EOF

  pkgadd  -a ${ADMIN_FILE}  -d ~/slim_source/packages/i386/nightly-nd -R /rpool/dc/build_data/pkg_image SUNWgui-install
This script simply takes a custom SVR4 package version of SUNWgui-install which I have built in ~/slim_source/packages/i386/nightly-nd and installs it to the default package image area /rpool/dc/build_data/pkg_image.
Once you've edited your manifest xml file and added your custom finalizer script entry, just re-run distro_const to generate your ISO as specified in the previous section.

10. Using Distro Constructor Checkpoints

Distro Constructor very conveniently builds your image in stages, each of these stages is checkpointed with a zfs snapshot, which makes it really simple to pause or restart a build from a given checkpoint. See Building An Image In Stages for complete details, I'll briefly describe what I do here.

To get a list of checkpoints from my presiously run mydistro.xml described in previous section :

$ pfexec distro_const build -l mydistro.xml
  /usr/share/distro_const/DC-manifest.defval.xml validates
  /tmp/slim_cd_x86_temp_28221.xml validates

  Step           Resumable Description
  -------------- --------- -------------
  im-pop             X     Image area creation
  add-custom-pkgs    X     Add custom pkgs
  im-mod             X     Image area modifications
  slim-im-mod        X     Slim CD Image area Modifications
  ba-init            X     Boot archive initialization
  slim-ba-config     X     Slim CD boot archive configuration
  ba-config          X     Boot archive configuration
  ba-arch            X     Boot archive archiving (64-bit)
  ba-arch-32         X     Boot archive archiving (32-bit)
  slim-post-mod      X     Slim CD post boot archive image area modification
  grub-setup         X     Grub menu setup
  post-mod           X     Post boot archive image area modification
  gen-slim-cont      X     Generate Slim CD image content list
  iso                X     ISO image creation
  usb                      USB image creation

The "X" in the Resumable column indicates you can resume operation from this point with the -r flag. To resume from a give checkpoint this step must have already completed in a previous run. When using a finalizer script to generate my ISO's, If I have changed something and would like to regenerate my ISO, rather than having to regenerate the complete pkg-image from your preffered IPS Repo (step "im_pop"), I tend to simply re-run the distro_const build from the step "add-custom-pkgs".

The steps that I follow are :

  • When a new development build of OpenSolaris is made available I run a complete distro_const build from scratch e.g.
    $ pfexec distro_const build mydistro.xml
    
    If nothing has changed in the development repository that I am dependent on, then there is no need to re-run the population of the pkg-image for your ISO from an IPS repository, as this takes some time, it makes sense ot skip it if you can.
  • For each subsequent ISO generation I simply update my add-custom-pkgs script, and re-run distro_const starting at the add-custom-pkgs step :

    $ pfexec distro_const build -r add-custom-pkgs mydistro.xml
    
    This will skip the image population step (saving potentially hours of time), and will start with adding your custom packages. The -r option rolls back to the start of that step, e.g. before custom packages were added (ZFS Rocks !), and will re-add your custom packages all over again.

11. Summary And Links

Well done you made it to the end of what turned out to be a lot longer that I had originally planned. If you find errors in the above, please let me know and I will update the blog.

Some handy resources :

Wednesday 17 December 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 21 October 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.

wnckprop utility is delivered on OpenSolaris as part of the SUNWgnome-panel package. You can also download the latest source from the GNOME public server http://ftp.gnome.org/pub/GNOME/desktop

It should build quite easily regardless of the flavour of *nix you are using. As I use OpenSolaris here's some useful links :

  Desktop GNOME Community on OpenSolaris
  JDS Project on OpenSolaris
  Building JDS On OpenSolaris

Friday 20 July 2007

Using Glade-3 for a bit of tile design


Everyone who owns a house knows that there is always an endless list of things that need to be done. One of the items on my personal list happened to do some tiling in behind a section of our stairs that the plasterer could not reach.

Now while on holiday in India a few years back, one of the places we visited was Jaipur, or the pink city. Something not so well known about Jaipur is that they are also famous for the blue pottery. We bought some coat hanger hooks which had some blue tiles. This got me thinking that it would be great to use some similar tiles for our little spot of tiling.

But then the problem was what tiles to use, what and what would they look like, there are hundreds to choose from and all various sizes. So I thought to myself how would I know what the final product I need some tool that I can simply plug in a set of images, and it will arrange them just like they are on a wall. And I decided to use glade-3, with simple window containing a GtkTable, and loads of GtkImages, one for each tile.

It was really cool, and worked a treat...

Tuesday 17 July 2007

Arrived at GUADEC '07

Just arrived at GUADEC '07 yesterday to the 2nd warm up day, somewhat tired but great to see all the usual faces and lots of new ones. Althought getting up at 4am to catch my flight to Birmingham is something I will never get used to....

Thursday 28 July 2005

Netbeans 4.1....

Just for the record here, I am a complete novice when if comes to Java, I've never written a java programm, I did hack a java scrolling applet once, but that was a long time ago... But it did let me see some java code.
I decided after 8 years of working in Sun, it was time to learn a little Java, after all where else better to learn Java than the place of it's invention.So I went to http://java.sun.com and clicked on the download icon for Netbeans 4.1, 4.2 is available as a beta, but as I am just starting off, stability was a pre-requisite. So I downloaded and installed on my JDS 3 Linux laptop, all very smooth indeed, launched it and excellent, the opening page gives you a nice pointer to a quick start tutorial on how to create a new java general application.
I thought yep, that's for me... gave a quick read, and created MyLib and MyApp and got it compiled and running in no time. But that was the real easy bit, realistically I should get a book and learn the language properly before diving in head first into an IDE, but I suppose I'm just impatient and I've heard so much talk that "it's very C Like", and thought "hey, I know C pretty well, how hard can it be...".
So there was no real surprise, the java syntax is indeed very C/C++ like, but there are also items very similar to VB (Visual Basic), another language I am familiar with from previous life.
This is one of the reasons I was very interested in Netbeans as an IDE in particular and to see how it stands up against VB. That brings me to the next step, designing a form.
After a few teething problems getting to know the various layout engines and understanding what all (some) of the swing objects that can be added to a form are all about, containers and the likes, I did manage to create a form with loads of buttons,text fields etc, all great and easy to add. The GridBagLayout engine is really powerful, once you know how to use it.
I do have one gripe though, when adding say loads of JTextFields to a container I could not see the facility to add these as an array !, which is very easy to do in VB, by adding them as an array I could then simply use the one listener method say for FocusIn rather than having to have separate listener methods for each instance of JTextField, I'm sure it can be done, it's just not intuitive. Within VB if you Copy/Paste an object it prompts whether you want to create an object array or not, very handy.
I ended up creating my own text field class, which extends JTextField, adding some listener's in here, and then manually within code, replacing the individual JTextFields I had created with instances of my new MyTextField.
My next stage of learning is now adding some functionality to my form....