Wednesday Sep 21, 2011

Closed TRACKED in Bugster Update - September 2011

Similar to previous posts [1] [2] [3], [4] here's the latest statistics as run this morning.

 1-Dispatched                                      153
 2-Incomplete / Need More Info                      18
 3-Accepted                                        140
 4-Defer                                             7
 4-Defer / Code Freeze                               2
 4-Defer / Future Project                            4
 4-Defer / No Plan to Fix                            7
 4-Defer / No Resource Available                    26
 5-Cause Known                                      25
 6-Fix Understood                                   13
 7-Fix in Progress                                   2
 8-Fix Available                                     6
10-Fix Delivered                                   420
10-Fix Delivered / Needs Verification                1
10-Fix Delivered / Verification Not Needed           1
10-Fix Delivered / Verified                        109
11-Closed / Duplicate                              290
11-Closed / Not Reproducible                       198
11-Closed / Not a Defect                            89
11-Closed / Unverified                               8
11-Closed / Verified                                67
11-Closed / Will Not Fix                            84
                                                 -----
                                                  1670
                                                 -----

You'll notice that the output is slightly more detailed than previously. I've revamped the script that generates this, to use BeautifulSoup.

[]

[]

[]

Tuesday Mar 15, 2011

Closed TRACKED in Bugster Update - March 2011

Similar to previous posts [1] [2] [3], here's the latest statistics as run this morning.

    1-Dispatched:         204   
    2-Incomplete:          34   
    3-Accepted:           188
    4-Defer:               53
    5-Cause Known:         30   
    6-Fix Understood:      15
    7-Fix in Progress:      4
    8-Fix Available:        6
    10-Fix Delivered:     464
    11-Closed:            618
                       ------
                         1616
                       ------

[]

[]

[]

Tuesday Jan 05, 2010

Closed TRACKED in Bugster - Latest Statistics

For the past 11 months, I've been moving certain bugs in the "hardware", "kernel", "networking" and "software" categories in the OpenSolaris Bugzilla bugs database, over to the Sun internal Bugster bugs database, to hopefully get the attention of Sun engineers who don't monitor Bugzilla.

See two previous posts [1] [2] for more details

I ran the stats again this morning. 1176 bugs have now been moved over (not all by me), and they are currently in the following states in Bugster:

    1-Dispatched:         193    
    2-Incomplete:          53    
    3-Accepted:           145  
    4-Defer:               47
    5-Cause Known:         12     
    6-Fix Understood:      13        
    7-Fix in Progress:      8
    8-Fix Available:       17       
    10-Fix Delivered:     306       
    11-Closed:            382

Time permitting, I think I'll try to do a little more analysis on the ones still in a "Dispatched" state, to see if there is commonality and whether there is anybody that needs a prodding.

Update: I found some time. A list of all the Dispatched "Closed TRACKEDINBUGSTER" bugs sorted by product/category/subcategory and priority/severity can be found here.

[]

[]

[]

Monday Nov 09, 2009

Instructions For Changing an OpenSolaris Unbundled IPS Package

[Last updated 12th July 2010 to work with build #134. Thanks to Chris Quenelle for working out what changes were needed to the scripts used for publishing].

Yet another project team need to upgrade their unbundled OpenSolaris software, so it's time to write out the instructions and just point them at them. They will need to adjust to taste. These instructions are also some what Oracle-internal specific.

When I'm updating one of the unbundled OpenSolaris packages, then I'll do something like the following. There needs to be a bug number in the OpenSolaris Bugzilla for this work, so let's pick 13523 (the recent one used for NetBeans 6.8):

  1. Check out the latest pkg source workspace:

          $ mkdir -p ~/pkg/bugs/13523
          $ cd ~/pkg/bugs/13523
          $ hg clone ssh://anon@hg.opensolaris.org/hg/pkg/gate
          

  2. Make any changes to the unbundled IPS package manifest file.

    For example, if you wanted to change the version number for the NetBeans packages, then you would edit the .../gate/src/util/distro-import/unbundleds/NetBeans file and adjust the version lines accordingly.

  3. Build and install your workspace:

          $ cd gate/src
          $ make -e; make -e install; make -e packages
          

    You might need to setup your OpenSolaris machine so that the build process will work. I have some notes from about a year ago, when I went through this.

    Note that the pkg build process doesn't currently work properly with GNU Makefile, so make sure your PATH is something like:

          export PATH=/opt/sunstudio12.1/bin:/usr/bin:/usr/sfw/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/gnu/bin
          

    so that it picks up the correct make executable.

    There are a couple of packages you might need to install to get pkg (and associated packaging commands) to run properly. These are:

            $ pfexec pkg install SUNWpython26-pyopenssl
            $ pfexec pkg install SUNWpython26-simplejson
          

  4. Copy three shell scripts (originally written by David Comay):

    start-depotd
    start-import
    start-cluster

    into ~/pkg/bugs/13523/gate and adjust them accordingly. If you look at them, you'll hopefully see what needs to be tweaked for your unbundled package. Let me know if you need more details.

  5. Run a local pkg.depotd server

    In one terminal window, I'll start up the pkg.depotd process by running:

          $ cd ~/pkg/bugs/13523/gate
          $ start-depotd
          

    and then monitor it with:

          $ tail -f errs.depotd
          

  6. Before I can publish my unbundled package, I need to publish any WOS ON package to my local repository. This needs to be done otherwise certain things in the publish process aren't setup correctly:

    In another terminal window, I'll start up the importer.py package publishing process with:

          $ cd ~/pkg/bugs/13523/gate
          $ start-import
          

    and then monitor it with:

          $ tail -f errs.import
          

    Note that you should set:

    JUST_THESE_PKGS to just the single package you'd like published (in this case driver/firewire). If you are building against an earlier build before the Great Renaming (which occurred in build #133), then you will need to pick one of the old style package names. I suggest SUNWiscsi.

  7. Now it's time to publish the unbundled package. I do this in yet another terminal window with:

          $ cd ~/pkg/bugs/13523/gate
          $ start-cluster
          

    and then monitor it with:

          $ tail -f errs.cluster
          

    Adjust PKGS in the start-cluster script to the location of the new unbundled SVR4 packages you want to publish.

    The start-cluster script is now setup to publish against build 134. If you want to publish your unbundled packages against another build (say 126), then adjust the BUILDNO= line accordingly.

    If it's successfully published the packages to my local repository, I can then look at them via my browser at http://stard.sfbay.sun.com:13523

  8. I will then need to install and test my new packages:

          $ pfexec pkg set-authority -P -O http://stard.sfbay.sun.com:13523 bug13523
          $ pfexec pkg install developer/netbeans
          $ pfexec pkg set-authority -P opensolaris.org
          $ pfexec pkg unset-authority bug13523
          
  9. Then I'll test these new package(s), and repeat steps 2-8 as needed.

  10. When things are looking good, you will need to get a code review. For simple changes like this, the differences can be sent as part of the message to the pkg-discuss mailing list. Use:
          $ hg diff
          
    to get a set of diffs for the changes you've made. An example of such a code review request can be found here.

  11. When the code review request has been approved, then the changes need to be checked into the pkg source workspace. Initially unbundled project team members won't have checkin permission to this workspace, so they will need to send the diffs to somebody who does.

    First commit the changes:

          $ cd ~/pkg/bugs/13523/gate
          $ hg commit
          

    This puts you in the text editor. Add a one line comment to describe the change. Something like:

          13523 Integrate NetBeans 6.8 as an unbundled package  
          

    Note the changeset number with:

          $ hg tip
          changeset:   1954:bef1d4d2996f
          user:        Rich Burridge 
          date:        Wed Jun 23 07:30:54 2010 -0700
          summary:     13523 Integrate NetBeans 6.8 as an unbundled package
          

    Export the changeset:

          $ hg export 1954:bef1d4d2996f >~/PKG-EXPORT/pkg-13523.patch
          

    and then send the pkg-13523.patch file to the pkg developer who can check it in for you.

[]

[]

Tuesday Jul 14, 2009

Instructions For Testing an OpenSolaris IPS Package Change

I've written these notes out for two people so far, so it's probably time I created a blog post. I can then just point future interested parties here, and they can adjust to taste. The notes are some what Sun-internal specific.

When I'm trying to fix a bug that involves changing the way that an IPS package is created from an SVR4 package, then I'll do something like the following. (This was for bug #9683):

  1. First I check out the latest pkg source workspace:

          $ mkdir ~/pkg/bugs/9683
          $ cd ~/pkg/bugs/9683
          $ hg clone ssh://richb@hg.opensolaris.org/hg/pkg/gate
          

  2. Next, I'll edit the files in the workspace as appropriate and build it:

          $ cd gate/src
          $ make -e; make -e install; make -e packages
          

    You might need to setup your OpenSolaris machine so that the build process will work. I have some notes from about a year ago, when i went through this.

    Note that the pkg build process doesn't currently work properly with GNU Makefile, so make sure your PATH is something like:

          export PATH=/opt/SunStudioExpress/bin:/usr/bin:/usr/sfw/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/gnu/bin
          

    so that it picks up the correct Makefile.

  3. Next, I'll copy two shell scripts, start-depotd and start-import (originally written by David Comay) into ~/pkg/bugs/9683/gate and adjust them accordingly. If you look at them, you'll hopefully see what needs to be tweaked for your situation. Let me know if you need more details.

  4. Next I need to run a local pkg.depotd server

    In one terminal window, I'll start up the pkg.depotd process by running:

          $ cd ~/pkg/bugs/9683/gate
          $ start-depotd
          

    and then monitor it with:

          $ tail -f errs.depotd
          

  5. Next I need to publish my new package(s) to my local repository:

    In another terminal window, I'll start up the solaris.py package publishing process with:

          $ cd ~/pkg/bugs/9683/gate
          $ start-import
          

    and then monitor it with:

          $ tail -f errs.import
          

    Note that you should set:

    JUST_THESE_PKGS to just the list of packages you'd like publish (space separated).

    WOS_PKGS to a list of the places where you can find the SVR4 packages (space separated). In other words, add the location of your new SVR4 packages to the front of this list. This will be something like:

          export WOS_PKGS="/where/my/packages/are /net/netinstall.sfbay/export/nv/x/111/Solaris_11/Product/"
          

    The script is setup to publish against build 111. If you want to publish against another build (say 118), then adjust the two occurrences of "111" accordingly.

    If it's successfully published the packages to my local repository, I can then look at them via my browser at http://stard.sfbay.sun.com:29683

  6. I will then need to install and test my new packages:

          $ pfexec pkg set-authority -P -O http://stard.sfbay.sun.com:29683 bug-9683
          $ pfexec pkg install SUNWcs
          $ pfexec pkg set-authority -P opensolaris.org
          $ pfexec pkg unset-authority bug-9683
          
  7. Then I'll test these new package(s), and repeat steps 2-6 as needed.

[]

[]

Tuesday Apr 14, 2009

Closed TRACKEDINBUGSTER - Two Months Later

See a previous post for more background.

Well it's almost two months on, and I've shuffled a load more bugs over to Bugster, so I thought I'd run my script again.

There are now 644 bugs that have been closed in OpenSolaris Bugzilla as TRACKEDINBUGSTER. Here's their current status, this time with percentage figures:

1-Dispatched:           146       22.67%
2-Incomplete:           24         3.72%
3-Accepted:             70        10.87%
4-Defer:                16         2.48%
5-Cause Known:          6          0.93%
6-Fix Understood:       6          0.93%
7-Fix in Progress:      15         2.33%
8-Fix Available:        11         1.71%
10-Fix Delivered:       179       27.80%
11-Closed:              171       26.55%

[]

[]

[]

Monday Mar 02, 2009

Backing Up Your Twitter Posts

Now I'm twittering I wanted to make sure I had a way to locally save my pearls of wisdom drivel. From googling, I'd found tweetake and twistory but didn't like the idea of passing over my username and password to a site I didn't know.

I then stumbled on a Python frontend to the Twitter API. I downloaded the compressed tarball and unpacked, built and installed it with:

  $ gzip -dc python-twitter-0.5.tar.gz | tar -xvf -
  $ cd python-twitter-0.5
  $ python setup.py build
  $ pfexec python setup.py install

Now "backing up" my tweets is as simple as running:

  $ python backup.py > richb-tweets.txt

where backup.py is:

    import twitter

    api = twitter.Api()
    statuses = api.GetUserTimeline("richburridge")
    for s in statuses:
        date_ts = " ".join(s.created_at.split()[:4])
        print "%s: %s\\n" % (date_ts, s.text)

for output that looks like:

Mon Mar 02 20:39:10: Oooh! Twitter has a Python front-end to it's API: http://code.google.com/p/python-twitter/ I can see hours of tinkering ahead.

Mon Mar 02 19:10:46: Added twitter monitor thingy to left column on main blog. Didn't help that Twitter went oopsie while I was debugging this.

...

(Adjust the "richburridge" user name to your own, if you want to use this).

Still lots more to explore with python-twitter, but that's enough for today.

[]

[]

[]

Tuesday Feb 17, 2009

Closed TRACKEDINBUGSTER

For the past couple of weeks, I've been triaging bugs in the kernel and software sub-categories in the OpenSolaris Bugzilla bugs database.

Bugs that are filed in these two sub-categories tend to be catchalls for all the bugs that don't have another existing product/cat/sub-cat. defined that they could go into. They are also typically dumping grounds for bugs that are not being actively looked at by Sun engineers.

OpenSolaris releases are currently based on Nevada builds. We just take the SVR4 packages that the Nevada distributions create, and convert them into IPS packages and put those in network repositories or deliver via updated ISO images of the Live CD.

If we want these bugs to be fixed properly, then those fixes need to be applied to the Nevada sources. In order to get the Sun engineers to do that, they need to be aware of the bugs. That's why they are being transferred over to the Bugster database and closed here.

It's far from a perfect system, but hey, you work with what you've got.

In doing this bug transferring, I noticed that a lot of the new bugs that I'd filed in Bugster, were being actively picked up and worked on. That got me curious on just how successful this reverse transfer has been.

I wrote a small Python script that did a query to get a list of all the bugs that have been closed as TRACKEDINBUGSTER, and then scrapped this to get a list of all the BugsterCR values from their Whiteboard fields. I then used an internal Bugster->Web web site, to read each of those bug reports and extract the Status field. I then summarized the results.

(I fully appreciate that this would be much easier if I used SQL to integrate these bugs databases, but I don't know how to do that, or even where to go to find out how to do that).

Currently there are 400 bugs that have been closed in OpenSolaris Bugzilla as TRACKEDINBUGSTER. Here's their status:

1-Dispatched:           99
2-Incomplete:           19
3-Accepted:             59
4-Defer:                8
5-Cause Known:          4
6-Fix Understood:       3       
7-Fix in Progress:      10      
8-Fix Available:        6       
10-Fix Delivered:       109
11-Closed:              87

The real bug that needs to be fixed here is to get the Sun engineers to actively monitor (and respond to) all bugs that are filed at defect.opensolaris.org (and I understand that that is being worked on), but it's nice to know that this triaging is having some effect, rather than all those open bugs just lying stagnant.

[]

[]

[]

Tuesday Jan 13, 2009

How To Contribute Software To OpenSolaris

As you've probably seen from a previous post, we now have OpenSolaris IPS pending and contrib repositories. On the web pages referenced there, are some instructions on how to go about contributing your own favorite software to these repos.

This is great, but what's needed is a step-by-step guide with an example.

John Sonnenschein is a new member of our team, and is going to help out with OpenSolaris packaging. I recently asked him to investigate what it would take to create a .spec file for Drupal, so that it could then be a candidate for the "pending" OpenSolaris IPS repository.

He's now done that, and blogged about all the steps and included the sample .spec file.

It looks good (thanks John). I asked him:

"How did you solve the there-is-no-scripting-in-IPS part"?

and he replied:

"I didn't need to for Drupal. The first time the user connects to the server it'll go through the setup script as a function of how Drupal works. It complains to the user with instructions how to set it up if the .php itself can't do the work."

Excellent. A properly written software package.

Hopefully John's note can be used to help others easily contribute their favorite missing packages to OpenSolaris.

[]

[]

Monday Jan 05, 2009

Radio Paradise on OpenSolaris?

This year, I'd really like to swap over to using OpenSolaris as my default desktop at home if possible, but there are several things that are just not there yet, and are therefore preventing me from doing so.

The first one is being able to listen to my favorite Internet radio station. If I click on any of the "listen" links (such as the 128k MP3 one in my Firefox browser, I get the "Opening rp_128.m3u" popup, with Totem Movie Player as the default application. If I try to run that, Totem bitches that:

An error occurred The playback of this movie requires a MPEG-1 Layer 3 (MP3) decoder plugin which is not installed [ OK ]

Unfortunately it doesn't just ask me if I'd like to install one (like Ubuntu does the first time I try this on that platform). Also my Mac and Windows XP machine "just work", right out of the box.

I then tried Songbird. Same problem.

I found a LifeHacker entry on Radio Beta that looked promising. I entered "Radio Paradise" in the Quick Search field, and then clicked on the Play icon for the entry that it found. It then bitches that:

In order to listen to this radio, please download VLC and Firefox plugin (for MacOS X and Linux users.)

I clicked on that download link, and found that for Solaris (and therefore presumably OpenSolaris), that there are no precompiled binaries and that I would have to get the source code and build it myself.

My interest started to wane at this point.

Am I missing something? Is there a package I can just install that will allow me to do what I want on OpenSolaris?

[]

[]

[]

Wednesday Dec 10, 2008

OpenSolaris Pending and Contrib Repositories Online

With the official launch today of OpenSolaris 2008.11, we see two more package repositories coming online.

  • pending - contains packages contributed from the community or by package generation programs that have completed the pending repository process. Packages in this repository are not qualified and are for "use at your own risk".

  • contrib - contains packages contributed from the community that have completed the contrib repository process. Packages in this repository have gone through some qualification but are still at a "use at your own risk".

(Admittedly the pending repository has been there for a few days).

If you are interesting in contributing more F/OSS packages to OpenSolaris, then check out the sw-porters contributing web page for all the details.

[]

OpenSolaris 2008.11 - It's Available!

You've been patiently waiting, and we can now finally blog about it. After a lot of hard work by a lot of people all around the world, the new release is available for you to download now. It's easy to use and simple to install. Lots of new features for you to check out.

See the online documentation on how to use it and for what's new. I hope everybody will give it a try as soon as possible, because this is the one everything else will be compared against.

[]

Wednesday Dec 03, 2008

It's Available!

You've been patiently waiting, and it's finally ready. After a lot of hard work by a lot of people all around the world, the new release is available for you to download now. It's easy to use and simple to install. Lots of new features for you to check out.

See the online documentation and what's new. I hope everybody will give it a try as soon as possible, because this is the one everything else will be compared against.

What? You didn't think I was blogging about something else did you?

[]

Wednesday Nov 19, 2008

The IPS Code Swarm

You've seen the code. Now watch the video.

Albert White has put together a blog entry today about OpenSolaris Code Swarms.

There is a great video, which is a graphical representation of the development over time of the Image Packaging System, (which I started checking packaging changes into a couple of months ago). I just love how large scale changes are represented (such as the integration of a new WOS build with many new or changed packages).


Image Packaging System Code Swarm from Albert White on Vimeo.

(Thanks Alan).

[]

[]

Wednesday Nov 12, 2008

Getting the Freenode Channel List

This should have been a simple task, but it took longer than I expected. Perhaps somebody can show me a quicker, better way to do this.

I've been connecting to the #pkg5 IRC channel on freenode.net for the last few days, and today I went to see what other channels were there. I'm using pidgin 2.5.1 on OpenSolaris 2008.11 (build 101a).

I knew enough about IRC to type /list in the input area at the bottom of my conversation(s) window. When I do that, up comes a popup dialog with a room list. I can click on the column headers to sort it in various ways. Neat. How to I save the information, so I can process it? Darned if I know. I furtled around in various menus and preference dialogs, couldn't find anything useful and gave up.

I then installed XChat 2.8.6. Under the Server menu, there is a List of Channels... menu item which brings up another popup dialog of the Channels List. Again, you can sort in various ways, but there is also a Save List... button. Yay!

I now have a text file containing a full channel list, sorted by the number of users, and from this I can extract useful URL's provided as part of the various channel descriptions.

[]

[]

About

user12607856

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
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