Friday Oct 24, 2008

Trying To Fix the Intrusive Firefox

You may remember from a previous post, that if I clicked on a hyperlink in Thunderbird, then Firefox would be intrusive and start up on my current desktop.

The "workaround" was to set "browser.tabs.loadDivertedInBackground" to True via "about:config" in Firefox.

Bug 175904 on Ubuntu's Launchpad has been tracking this problem, and on Monday, an interesting workaround appeared from Jeremy Nickurak

I wrote up a script that I call on opening URL's instead of calling firefox directly. It checks to see if there's a firefox window on the current desktop. If there is one, it'll focus it, and open the URL in a new tab there. If there isn't one, it'll just open a new window right where you are.

Hopefully this'll be useful to somebody.

It requires wmctrl to be installed. (sudo apt-get install wmctrl)

The script is attached to the bug. I thought I'd give it a try.

Well there is no equivalent of sudo apt-get install wmctrl on my OpenSolaris box at the moment, so I downloaded the tarball for wmctrl, unpacked it and tried to build it with:

  $ gzip -dc wmctrl-1.07.tar.gz | tar -xvf -
  $ cd wmctrl-1.07
  $ ./configure --prefix=/usr
  $ make
  $ pfexec make install

Unfortunately it bitched about not having some of the X11 header files, so I had to do:

  $ pfexec pkg install SUNWxwinc

before I was able to successfully build and install it.

Now I needed to get Thunderbird to recognize the new firefox-tab script. I put a copy of it in my own personal bin directory and gave it execute permission:

  $ cd ~/bin
  $ mv ~/Desktop/firefox-tab .
  $ chmod +x firefox-tab

As I previously had set "browser.tabs.loadDivertedInBackground" to True via "about:config" in Firefox, then I had to revert that. I restarted Firefox for good measure.

Then I needed to terminate Thunderbird and add three lines to the prefs.js file in my current Thunderbird profile (~/.thunderbird/hd7h4tp9.default/prefs.js):

  user_pref("", "~/bin/firefox-tab");
  user_pref("", "~/bin/firefox-tab");
  user_pref("", "~/bin/firefox-tab");

I then restarted Thunderbird and clicked on a hyperlink. Even though I had Firefox running on a different workspace with several tabs in it, it started up a new Firefox window on my current workspace (where Thunderbird was running). Hmm.

It's definitely running ~/bin/firefox-tab. It's just not doing the right thing. If anybody has any ideas why this isn't working, I'm all ears. For now I've gone back to my previous "workaround".




Thursday Oct 23, 2008

Determining Changes In The OpenSolaris Mercurial World

Coming from the GNOME open source development world, I'm used to seeing active discussion in the GNOME bugs, including patch attachments for the proposed fixes, and then a ChangeLog entry that lists the files that have changed and a description of the fix.

The way that the OpenSolaris pkg engineers work is different. They've got their own equivalent Bugzilla bug database, but patch attachments are rare, and usually the last comment in the bug is something like:

  Fixed in changeset ee3df64105403de274760b7de3bf78546105350b

which is not immediately useful if you want to see how the bug was fixed.

But it's not too much more work to derive a patch from that or a list of files that have changed, if you know the appropriate magical incantations.

First, find a wizard. In my case, I asked Danek Duvall.

Here's an example based on a recent change of mine to the pkg source workspace to make a slight adjustment to the fix for bug #2198. You'll see the last changeset value in comment #13. Let's turn that into a patch and a list of files that were changed.

If you want to follow along at home, you will need to first checkout a copy of the hg workspace:

  $ hg clone ssh://

To get a list of files that changed in a particular rev, first look at the log:

  $ cd gate
  $ hg log | more
  changeset:   619:ee3df6410540
  tag:         tip
  user:        Rich Burridge <...>
  date:        Thu Oct 23 08:08:45 2008 -0700
  summary:     2198 Need cluster packaging for 3.0 (fix versioning)

  changeset:   618:7be9399f34fc
  user:        Bart Smaalders <...>
  date:        Wed Oct 22 18:51:16 2008 -0700
  summary:     4174 need hostid workaround for build 100a

From that, to get a list of the files that changed between rev #618 and #619, do:

  $ hg stat --rev 618:619

To get a list of the changes in diff (patch) format for rev #619, you simply do:

  $ hg log -p -r ee3df6410540

(Thanks Danek!)




Tuesday Oct 14, 2008

Minor, the New Normal

Is it just me, or shouldn't the default Severity setting for new bugs being entered at, be normal not minor?

The choices are:

  • blocker
  • critical
  • major
  • normal
  • minor
  • trivial
  • enhancement

There's normal, sitting in the middle. Why isn't that the starting Severity? That's the way it works for GNOME and Mozilla.

Same for Priority. P3's in the middle, yet the default is P4.

Color me confused.



Wednesday Oct 08, 2008

Arduino Night At The Next SVOSUG Meeting

Alan Duboff has just announced details of a special Arduino night at the next Silicon Valley OpenSolaris User Group meeting in Santa Clara on Thursday 23rd October 2008.

I plan to be there. I better dust off my Arduino board.

Work is on-going in getting the full Arduino development environment running on OpenSolaris, but things are coming together nicely, mainly due to the work of Alan and John Plocher and John Weeks.

There will be a limited number of kits available at the meeting, so if you are interested in this, it is suggested that you get one ahead of time. See the various links in Alan's post for places that sell the kits.

For a good introduction to the world of Arduino, then I suggest the various lessons provided by ladyada.



Wednesday Sep 10, 2008

Two OpenSolaris Individual Contributor Positions Available

We have a couple of openings in my current group that I think would be of interest to any software engineers that know Linux and/or [Open]Solaris and enjoy the challenge of porting F/OSS software to new platforms.

"Be a part of the team that helps expand the OpenSolaris repository of externally contributed Open Source software. Help port the essential applications to the OpenSolaris platform and make them available to the community. Apply your Linux skills to enable these applications to be successful in the OpenSolaris world. This is your chance to be an integral part of building the community for one of the major open source operating systems".

As you can see, we are targeting Linux developers. Knowledge of [Open]Solaris is useful but not essential.

These are entry level positions. For more information, check out the web links (559524 and 559525).




Tuesday Sep 02, 2008

Pkg Test Repository Experiments

I've been playing around with setting up my own IPS test repository, then adding in a very simple package, then updating the meta-data associated with the package and then republishing the updated package.

Here are my notes based on the example on the IPS for Developers web page. Thanks to Shawn and Danek for pointing out the two mistakes there and giving me the correct commands.

  • Creating my own test repository:

    \* Start pkg.depotd:
      $ /usr/lib/pkg.depotd -d /export/home/richb/pkg/test_repository -p 9000
      I confirmed it was their by looking at http://localhost:9000 in a browser.

  • Creating a simple test package:

      # Create a temporary directory on your system.
        $ mkdir /export/home/richb/pkg/my_tmp
      # Change the directory to the temporary directory.
        $ cd /export/home/richb/pkg/my_tmp
      # Create a directory called my_package.
        $ mkdir my_package
      # Change the directory to my_package.
        $ cd my_package
      # Create a text file under the directory my_package.
        $ cp /etc/motd  my_text_file
      # Export the directory my_package. Specify a version number and a
      # sub-version number for the package. In this example, the my_package
      # has a version number of 1.0 and a subversion number of 1. Note the
      # back quotes used in this command.
        $ eval `pkgsend -s http://localhost:9000 open my_package@1.0-1`
      # Add attributes to the package. In this task you add a directory
      # action with attributes of mode, owner, group, and path. Path is
      # the key attribute for the directory action and has to be specified.
        $ pkgsend -s http://localhost:9000 add dir mode=0555 owner=root group=bin path=/etc/my_package
      # Add the file my_text_file under the my_package directory (with attributes)
        $ pkgsend -s http://localhost:9000 add file my_package/my_text_file mode=0555 owner=root group=bin path=/etc/my_package
      # We will add a dependency for this package and set a name attribute.
        $ pkgsend -s http://localhost:9000 add depend fmri=pkg:/depends_on_this_package@1.0-1 type=require
      # Add a description.
        $ pkgsend -s http://localhost:9000 add set name=description value="Example Package"
      # Use the following option to close the transaction.
        $ pkgsend -s http://localhost:9000 close

  • Grabbing the package out of a repository

    \* To grab my newly created "my_package out of my test repository:
      $ cd /tmp
      $ pkgrecv -s http://localhost:9000 pkg:/my_package@1.0,5.11-1:20080902T195702Z
    \* This created a directory called my_package under /tmp. Inside there 
      are all the files that are in the package plus a file called 'manifest'
      which contains the package's um, ... manifest.

  • Modifying the package's manifest:

    \* I added the following five lines to the end of the 'manifest' file:
    set name=package_display_name value="afio"
    set name=extended_description value="The extended description for this package that will go on and on and on"
    set name=category value="Operating System"
    set name=subcategory value="Core"
    set name=search_keyword_list value="keyword1,keyword2,keyword3,keyword4"
    These are an example of extra lines of meta-data that might be useful to a tool like

  • Republishing the modified package back to the test repository

    \* I put the package back in my test repository (with the same version
      number but a new timestamp) with:
      $ eval `pkgsend -s http://localhost:9000 open my_package@1.0-1`
      $ pkgsend -s http://localhost:9000 include -d /tmp/my_package /tmp/my_package/manifest
      $ pkgsend -s http://localhost:9000 close

The statistics and the catalog for the pkg.depotd at port 9000 now reads:


Number of packages: 2
Number of in-flight transactions: 0

Number of catalogs served: 3

Number of manifests served: 5
Number of files served: 0
Number of flists requested: 1
Number of files served by flist: 1
Number of packages renamed: 0

                 FMRI                           Info    Manifest
pkg:/my_package@1.0,5.11-1:20080902T195702Z     Info    Manifest
pkg:/my_package@1.0,5.11-1:20080902T210205Z     Info    Manifest




Monday Aug 11, 2008

Pkg Documentation and Mailing List Highlights

I've been trying to get up-to-speed on IPS, the Image Packaging System used by OpenSolaris. The project page has a lot of useful information, including the initial one pager and the manual pages.

There is also a discussion list. They have archives that go back to last September when the list was created. Over the last couple of weeks I've been wading my way through them. I've done this for the same reason that P.J. O'Rourke read The Wealth Of Nations: so you wouldn't have to. There is a lot of stuff there. Megabytes of it. A lot of it is really not interesting unless you are a pkg Python developer. What I've tried to do below is just give pointers to the things that I found interesting, above and beyond what the pkg project pages provide.

This isn't going to be the same things that are useful to others. There have been long debates on various design decisions. If you get off on this kind of thing, then please, just view the archives by thread, and find what excites you the most. If you don't have that kind of time, then maybe some of the links below will get you to the juicer bits.

Personally I would have like to have seen a separate pkg-bug-discuss (or some such name) list for the discussion of the various bug fixes. It would have made it a lot easier to get to the other stuff.

The links are in chronological order. The oldest first. I realize that because IPS/pkg is still being actively developed and is therefore "in flux", that some of these things are going to be out of date or just plain wrong. If you find any such links and have a pointer to better or correct information, then please comment.

Many thanks to the original posters who took the time to write up all this useful information.

  • pkg info for developers [link].
    pkg files associated with converting SVR4 packages to IPS repository format [link].
    (archive post).

  • Steps used to boot from an image built by IPS [link].

  • Multi-platform aspects of image packaging [link].

  • How to try Update Center (which is integrating the IPS Packaging system) [link].

  • An article by Peter J. Denning: "Mastering the Mess." [link 1]. [link 2].

  • An example of how to create an OpenOffice IPS package from the various SVR4 packages [link].

  • Early Prototype of what Update Center became [link].

  • SFW Buildable Source for OpenSolaris [link]
    (original post).

  • How to create my own packages for my application [link].

  • Best Practices for Developers document [link].
    (original post).

  • Requirements for an OpenSolaris endorsed/reference distro [link]
    (original post).

  • Where to submit bugs when you find them [link]

  • Latest thoughts on converting package formats [link].

  • An example of how to use the script [link].

  • Indiana IPS and "Imagine Prototype" #2 [link].
    (original post).

  • Latest pkg bug list [link].

  • Another example of using the script [link].

  • Using IPS to create minimal OpenSolaris configs [link].

  • Setting up Cadmium [link]

  • Create your own OpenSolaris IPS repository in a Weekend [link]
    (original post).

  • 10 Steps to Caiman Development on Indiana [link].
    (original post).

  • Tools to help build an SVR4 package [link].

  • How to use the pkg list and search commands [link].

  • How to submit a potential fix [link]

  • Plans for web interface? What would you like to see? [link]

  • Files associated with the Indiana project [link]
    (original post).

  • BE library for Snap Upgrade [link]
    (original post)

  • Revamping the server Web UI: Basic Action Plan [link].

  • Link to Package Manager Screencast [link].

  • Getting started with the Image Packaging System [link]
    (original post).

  • Packaging rules /guidelines and HOWTO [link]
    (original post).

  • How to handle hg (Mercurial) merges [link].

  • IPS supported actions [link].
    (original post).

  • A field guide to zones in OpenSolaris 2008.05 [link]
    (original post).

  • Script to make a copy of repository [link].
    (original post).

  • An example of how to install a package into a different location [link].

  • Tool to generate file lists in format compatible with pkgsend include files [link 1] [link 2] [link 3]

  • How to determine what your direct dependencies are [link].

  • How to define dependencies [link]

  • /contrib repository rough proposal [initial post].
    (Also read the numerous replies in this thread, to get a fuller picture of the challenges involved).

  • Is this an SVR4 package or an IPS package? [link]

  • Simple example of how to publish an SVR4 package [link].

  • Example of IPS packaging [link].
    (original post).

  • Building JDS on OpenSolaris [link].
    (original post).

  • IPS Packaging Best Practices When Using the Update Center Toolkit [link].
    (original post).

  • Finding the dependancies of a package [link].

  • Suggestion on how to debug ksh quoting problems [link].

  • Getting involved with contributing packages to IPS [link]

  • Sample Python script for testing progress on two data threads [link].




Monday Aug 04, 2008

What Is That OpenSolaris Package?

There is a small group of OpenSolaris engineers who have memorized all the names of the various Sun packages that are currently available and can tell you what they are and what they do.

This is no mean feat given that for quite a while, SVR4 package names were only 9 characters long and for the ones that came from Sun, the first four were typically "SUNW".

Being a mere mortal I haven't attained that level of enlightenment yet. So I put together this one-liner that helps me out.

  $ pkg info | nawk '{if ($1 ~ "Name:" || $1 ~ "Summary:") print $0}' > package-names.txt

Now if somebody mentions a particular package name, I can quickly furtle through my list and get its summary.



Friday Aug 01, 2008

Getting Audio Working With OpenSolaris On An Ultra 40

I started with OpenSolaris 2008.05 and yesterday updated to build 94. I'm now trying to get the audio working. I have a couple speakers connected to the light green audio socket on the back of the machine. As this is current Sun hardware, I was hoping it would "just work" out of the box. Unfortunately that is not the case.

Before somebody says "install OSS", I just did that. I then rebooted and when I ran osstest I got:

$ osstest
Sound subsystem and version: OSS 4.0 (b1016/200806171344) (0x00040003)
Platform: SunOS/i86pc 5.11 snv_94

\*\*\* Scanning sound adapter #-1 \*\*\*
/dev/oss/hdaudio0/pcm0 (audio engine 0): HD Audio play front
- Performing audio playback test... 
   OK  OK  OK  
/dev/oss/hdaudio0/pcm1 (audio engine 1): HD Audio play rear
- Performing audio playback test... 
   OK  OK  OK  
/dev/oss/hdaudio0/pcm2 (audio engine 2): HD Audio play center/LFE
- Performing audio playback test... 
   OK  OK  OK  
/dev/oss/hdaudio0/pcm3 (audio engine 3): HD Audio play side
- Performing audio playback test... 
   OK  OK  OK  
/dev/oss/hdaudio0/pcm4 (audio engine 4): HD Audio play pcm4
- Performing audio playback test... 
   OK  OK  OK  
/dev/oss/hdaudio0/spdout0 (audio engine 5): HD Audio play spdif-out
- Performing audio playback test... 
   OK  OK  OK  
/dev/oss/hdaudio0/pcmin0 (audio engine 6): HD Audio rec mix
- Skipping input only device
/dev/oss/hdaudio0/pcmin1 (audio engine 7): HD Audio rec mix
- Skipping input only device
/dev/oss/hdaudio0/pcmin2 (audio engine 8): HD Audio rec mix
- Skipping input only device
/dev/oss/hdaudio0/spdin0 (audio engine 9): HD Audio rec spdifin
- Skipping input only device

\*\*\* All tests completed OK \*\*\*

I heard their special test music only for:

/dev/oss/hdaudio0/pcm0 (audio engine 0): HD Audio play front
- Performing audio playback test... 
   OK  OK  OK  


/dev/oss/hdaudio0/spdout0 (audio engine 5): HD Audio play spdif-out
- Performing audio playback test... 
   OK  OK  OK  

which I thought was a little strange as the speakers are plugged into the back of the machine not the front.

I then inserted an audio CD and tried to run rhythmbox. Okay, I can live with it having plugin failures for "Magnatune Store", "Jamendo" and "Cover art", but it didn't want to play any music either.

I see that the little loud speaker icon in the top GNOME panel has a red bar through it.

If anybody knows the magic incantations to get this to work, I'll update this blog post with the instructions. Then hopefully the next person to google to try to find the answer will come across this post and have better luck then I currently am.


I should mention that I booted from the initial OpenSolaris 2008.05 image (which is build 86) and my audio CD plays just fine with Sound Juicer. Perhaps it's a build 94 specific problem...



Thursday Jul 31, 2008

The Power of pkg image-update and ZFS

One of the things that used to drive me crazy with working on the bleeding edge of Ubuntu (rather than the stable releases), was when a

      $ sudo apt-get dist-upgrade

of the latest packages and a reboot would leave me in a horked state. (Admittedly this was very rarely, but still: it did happen).

I then had to work out exactly which package blew me away (usually with the help of other people that were more experienced in this area then I was), and typically revert to an earlier more stable version.

Things are different under OpenSolaris with pkg. Yesterday afternoon, I ran:

  $ pfexec pkg image-update
  DOWNLOAD                                    PKGS       FILES     XFER (MB)
  Completed                                567/567 27150/27150 1648.05/1648.05

  PHASE                                        ACTIONS
  Removal Phase                              7140/7140
  Update Phase                             21974/21974
  Install Phase                            12389/12389
  A clone of opensolaris exists and has been updated and activated. On 
  next boot the Boot Environment opensolaris-1 will be mounted on '/'. 
  Reboot when ready to switch to this updated BE.

No need to reboot right away. No updating of live images. And really fast. Nice!

So this morning, I rebooted the machine. There was the new GRUB entry "opensolaris-1" (set as the default), and I went ahead and pressed Return to boot from that.

And it failed and eventually threw me back to the GRUB menu. Being a typical engineer, and failing to initially believe there was a problem here, I tried it again and it failed again.

But here's the nice part. I then simply selected the previous entry in the GRUB menu and booted from that. Now I'm back up and running nicely with the previous image.

I guess the next step in my education (or the next yak to shave depending how you look at it), is trying to work out exactly why the new boot image failed. Time to talk to some of the OpenSolaris engineers in adjacent offices.


Danek Duvall pointed me at the release notes (thanks!) and provided the magic mount command for this new OS image that is needed before you can do the update_grub command:

  $ $ su
  # beadm mount opensolaris-1 /mnt
  # pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
  Creating GRUB menu in /mnt
  Installing grub on /dev/rdsk/c5t0d0s0
  stage1 written to partition 0 sector 0 (abs 16065)
  stage2 written to partition 0, 265 sectors starting at 50 (abs 16115)

Now when you reboot, you'll see another new entry in the GRUB menu. Booting with that nicely works, and it's now a GNOME 2.22.X based system as opposed to a GNOME 2.20.X one.

Further Update

Dan Anderson pointed me at revised instructions for updating your OpenSolaris 2008.05 system (thanks!).




Wednesday Jul 30, 2008

Getting Pkg Built And Installed From Source On OpenSolaris

[Last updated: 12th January 2010]

On Monday I got OpenSolaris 2008.05 on my new work machine. I then followed step #2 in the release notes and updated to the latest packages.

I now want to be able to checkout the source code for the pkg project, build and install it, and start to try to understand how it all works.

Hopefully some day it'll be as simple as:

  $ pfexec pkg build-dep pkg
  $ pkg source pkg
  $ cd .../pkg_src_dir
  $ make install

but we aren't there yet. I couldn't actually find a set of step-by-step instructions on how to do this, so I muddled through. Thanks to the helpful folks on the #opensolaris channel on and various Google searches.

Before I could get the source code, I first had to get the Mercurial source control management system. That was with:

  $ pfexec pkg install SUNWmercurial

Getting the pkg project source code was with:

  $ hg clone ssh://

Most of the code is in Python, but there is some C. Before I could compile that, I needed to get a C compiler and all the things it needs. (I went with the Sun compilers). That's accomplished with:

  $ pfexec pkg install sunstudio12u1

I then added /opt/sunstudio12.1/bin to my PATH and /opt/SunStudioExpress/man to my MANPATH in my ~/.bashrc and sourced it

Trying to do:

  $ cd .../gate/src
  $ make install

in the pkg workspace, now resulted in compiler errors because a variety of standard C include files were missing.

Note that doing:

  $ pkg search -r <missing file>

gives the names of the package you need to install, then you can use the "pfexec pkg install" command to install that package. Rinse and repeat. Here are the packages I had to install:


Now back to pylint'ing. Looks like pylint isn't in the IPS repository yet, so I'll have to download and install it by hand.




Tuesday Jul 29, 2008

Mercurial Documentation

Now that I'm starting to work on OpenSolaris, I'll need to learn yet another source control management system. Just as I got used to CVS, the GNOME folks swapped to SVN. Just as I got used to that, I'll now have to start working with Mercurial.

I found the following links very helpful:




Friday Jul 25, 2008

Pylinting Again

Just like we did for Orca, I've been using pylint to find lint-like problems with the Python code for the GUI front-end to the OpenSolaris Image Packaging System (a.k.a. pkg).

See my post to the pkg-discuss mailing list on the current state of affairs with this.

As the official start date for my new job isn't until Monday, and I can't get into the Sun Menlo Park campus yet to use my spanking new OpenSolaris box, I've been building the pkg workspace on my Ubuntu Hardy system at home. Once I worked out all the dependencies to drag in all the C header files I needed, the rest of the build process was fairly straight forward. Some of the existing Makefile rules in the GUI Makefile are using Solaris make'isms, so they will have to be fixed up to work with something like GNU make. For now, I just hacked around it and got it all installed.

I find the current 8 space indentation jarring, and being an old fossil, I like my lines under 80 characters, but these are not the immediate things that will need changing. I hope they will get adjusted eventually though.







« July 2016