I’ve been testing Breezy Badger for the last few weeks to do my bit to help out with the latest release. I have been very dissapointed with Ubuntu’s method of bug reporting and handling. To put it bluntly it absolutely sucks. Debian (which Ubuntu is derived from) has an absolutely kick ass bug tracking system and is one of the best projects that I have ever worked on in terms of being able to report, search, categorise and generally manage bugs. Ubuntu seems to make it hard to do all of these things.

Attempt 1 to report a bug
I upgraded to breezy and was having a problem with Gnome freezing on login. I tracked this down to the fact that I had specified programs to run at startup in the session widget. Removing these prevented Gnome from freezing at the splash screen for two minutes. I wanted to report this bug. I fired up reportbug (standard Debian way of reporting bugs) and typed out the bug report. Went to send it, reportbug dies. It reported that the bug report had been sent to ubuntu-users@lists.ubuntu.com but as of today (a week later) it still hasn’t appeared in the archives there. I tried running report bug several times, and repeatedly got the same error message. It was 1am at night so I gave up on reporting the bug and went to bed.

Looking at my outgoing mail logs seemed to indicate that no outgoing email messages were generated, despite reportbug printing a message telling me that the report had been sent to ubuntu-users@lists.ubuntu.com and copied to my email address.

Attempt 2
Several days after bug attempt to file a bug about Gnome freezing on startup I ran into a problem with the network manager applet. Specifically its right click menu lacks the standard applet options such as Move, Lock to Panel and Remove from Panel. This makes it incredibly difficult to customise your panel to your liking. Having given up on being able to use reportbug to file a bug, I resorted to loading up mozilla and browsing to the Ubuntu website, where they recommend on the bug reporting webpage that you to file bugs in the Ubuntu Bugzilla. I dislike bugzilla a fair amount, it’s clunky, hard to use and I have to register to be able to submit bugs. I hate to think how a new Linux user would fare trying to report a bug this way. Anyway, I resolved to ignore my prejudice against bugzilla and sign up anyway. I trolled through Bugzilla for a while, carefully checking as best I could to ensure that I wasn’t going to file a duplicate bug. In the process of all this searching I continually stumbled across references to bugs filed in Malone and Launchpad that were not present in Bugzilla but were referenced.

From what I understand of Malone and Launchpad they are meant to be all-knowing, all-seeing “applications” that draw together bug reports, patches and releases from every distribution on the planet to make the package maintainers job easier. From what I can see at the moment, all they are achieving is to fragment bug reports and increase the amount of work it takes for maintainers and bug submitters to make useful contributions.

Eventually I decided that the bug wasn’t already reported in Bugzilla or Malone and I filed my report. 7 days later I haven’t had a response and I’m not getting my hopes up that I’ll get one soon.

Attempt 3
I ran a dist-upgrade this morning and pulled down the latest batch of updates. This upgraded (among other things) Xorg and Gstreamer. After the upgrade I attempted to start rhythmbox, which failed to start, displaying an error message telling me that I needed to run gst-register. Other gnome audio applications such as CD Player also reported that my plugin registry was corrupt and I needed to run gst-register. This seemed like a relatively simply bug to me, gstreamer just needs to run gst-register in its postinst script and all will be well. How should I go about reporting this bug? reportbug fails, bugzilla is hard to use, clunky and appears to be ignored (I base this comment on looking at other bug reports, not just on the lack of response to the bug above). I decided to give reportbug another try.

Searching through bugzilla I found that the bug I am encountering had already been reported, a month ago. As of today there has been no response from the maintainer, although there are several “me too” comments and confirmation that the bug is caused by a broken print statement when reportbug tries to display an informational message. I fired up vi and hacked the reportbug code (written in python) to disable the print statement which is entirely informational and then tried to submit the bug again.

Whee, reportbug now runs without errors and completes successfully, displaying nice messages telling me my bug has been submitted and copied to my email address. Great, all is happy in Ubuntu land. NO. Looking at my outgoing mail logs again seems to indicate that despite appearances reportbug still failed to generate any email at all, or if it did, it was submitted directly to Ubuntu’s SMTP server rather than using my local MTA.

Conclusion
Reporting bugs in Ubuntu sucks. There is much confusion over what method to use, Bugzilla appears to be recommended on the website, however cursory examination of the Bugzilla database doesn’t show much activity happening. The reportbug script is buggy and completely fails to work by default, when fixed it doesn’t appear to actually send any email at all, and even if it did send email it appears to be sending it to a completely different location than the Ubuntu Bugzilla which is supposedly the recommended location for bug reports. To complicate things even further, bugs reported from within Canonical seem to be reported in Malone and Launchpad rather than Bugzilla.

To Ubuntu’s defense the website does mention that bug reporting is “currently in a state of flux” and to please use the Bugzilla in the meantime. However that page has not been updated since it was created in April this year, so bug reporting has been in a state of flux for a long time.

What makes this situation all the more painful for me is that Debian’s Bug Tracking System is so excellent. Why Ubuntu haven’t chosen to use this is a mystery to me! The Debian BTS supports:

• Email bug submission and manipulation of existing bug reports
• Bug assignment and categorisation via system defined tags
• Tagging of bugs into user definable categories
• Version support to track where and when a bug is fixed
• Pretty web interface
• Excellent integration with reportbug script
• Easy to use searching
• Integration with the entire Debian package management system

Just about all of these features are missing in Ubuntu’s current setup.

I just fixed the bug that was causing some people to see duplicated side bars when viewing the wiki. It was introduced on Monday night when I made the change to display the sidebar by default.

Two sidebars were displayed when you visited the wiki without the wlug_sidebar cookie set in your browser. Once this cookie was set (which happens the first time you view the page) only one sidebar was displayed.

It’s amazing how many people complained about this! I guess I should have expected it based on my experiences with the site redesign a few months back, however it still manages to surprise me how closely people watch the Wiki layout and punch on things that are out of place. I guess it’s a good thing!

The 2005 WLUG AGM was last night and I’m pleased that we managed to get a full committee elected despite concerns on the topic. Overall I think the new committee has the potential to do a good job and I am feeling positive about the LUGs future.

Due to a last minute self nomination (5 minutes before nominations closed) we ended up having to vote for the 3 available general committee places as there were four candidates standing. While in general I like the idea of there being competition for committee places I was a bit dissapointed at how this particular situation turned out, and particularly dissapointed that Jon Purvis didn’t manage to make it onto the committee.

If you haven’t guessed already, I didn’t stand for re-election, for a number of reasons:

• I now live in Auckland which makes attending meetings difficult
• I’m finding more and more alternative projects that I want to have time to attend to
• It was time for a change
• I think it would be good for the LUG to draw some fresh blood into the “top ranks”

I still intend to be heavily involved in WLUG, most likely in the form of helping with Wiki administration and other tasks related to the website. My other goal for the next year is to try and push for the formation of a Linux NZ body. Hopefully now that I’m not on the WLUG committee I’ll have some more time to devote to this, and perhaps will be perceived as slightly more independent and separate from WLUG. If this all goes according to plan then it will probably mean that I’ll be in close contact with the new committee anyway.

So, thanks to the other committee members who I served alongside me, I enjoyed working with you all and best of luck to the new committee. I have high expectations for you

I have an IBM T42 laptop for work. This week I ordered an IBM Minidock so that I could attach an external LCD monitor, keyboard and mouse to the laptop to provide a nicer work environment seeing as I use it for 8 hours every day of the week. I ordered the setup from Ascent at 11am on Wednesday and after being told there was a two week lead time sat back to wait. 10am Thursday morning the courier turned up with the entire order! I was impressed.

Getting the laptop to work nicely with an external monitor took a little bit of work. I’m currently running Ubuntu Breezy. Breezy supports all the hardware in the laptop very well, however it hasn’t yet gained polish in dealing with configurations where you are coming and and out of the dock regularly. This is further complicated by the fact the the Minidock is actually a “dumb” dock and doesn’t generate ACPI dock events when the laptop is docked/undocked. The default setup configures X.org to use the ati driver. While this works fine the graphics card is better supported by the radeon driver, a one line change to the X.org configuration file.

I tried three different configurations to get the dual-head setup working nicely.

1. radeon driver using the MergedFB feature
2. radeon driver using xinerama
3. fglrx driver

The fglrx configuration utility couldn’t generate a configuration file that would work with Breezy, I suspect this is because Breezy has changed the Font Paths and fglrx config still tries to look in the old locations. I dropped the Files section from a working X.org configuration into the fglrx generated configuration which enabled X to start. The performance was terrible however, the second display didn’t work at all, and the Laptop’s built in LCD was flickering badly. Oh, and to get it to even this point I had to rmmod intel_agp and agpgart so that the fglrx driver could use its internal agpgart support. I gave up on fglrx very quickly. Proprietary code that seems to work half as well as the open source alternatives.

Next I tried the radeon driver using the MergedFB feature. This provides a single framebuffer across the two screens and seemed to work OK. The Laptop’s internal LCD always comes up as the primary monitor, this leads Gnome to place the panel and task list on it. I couldn’t find a way to change this. The merged framebuffer is the combined dimensions of the two screens (1400×1050 and 1280×1024), ie, 2450×1050. This leads to the second screen (external LCD) - which I want to use as my primary desktop scrolling up and down. Very annoying.

I finally settled on Xinerama as my preferred setup. This gives me two desktops, with the laptop still as the primary. However Gnome lets me create additional panels on the external LCD. I duplicated the menu list and taskbar from the primary display onto the external LCD. The only drawback I’ve found so far is that I only seem to be able to have one notification area. Even if I start an application like Gaim from the second screen it still adds itself to the notification area on the first screen.

A very bad quality (cellphone) photo of my new work desktop setup:

You can grab the X.org configuration I used from here.

The whole setup is a bit of hack, but I think it’s about the best I’m going to get for now and it works :).

As part of my effort to become more involved in Debian, I’ve recently adopted the PHPwiki packages which have been orphaned for quite a while and are in desperate need of some TLC.

David Moreno Garza is co-maintaining the package with me and sponsoring my uploads into the archive. We uploaded PHPwiki 1.3.10-1 today and it is slowly making it’s way through the buildd network, and hopefully into unstable sometime in the next day or two.

The next step is to package PHPwiki 1.3.11 to bring us in line with the latest upstream release. Once we have done that we need to tidy up the outstanding bugs on the package so that it can be considered for progression into testing.

Alongside all this Debian specific work, I’m also still trying to work on merging WLUG’s patches into PHPwiki 1.3.11 so that we can contribute to the PHPwiki community and hopefully revitalise it!

If you want to help out with this process please read the instructions on WlugWikiPatches, pick a patch and starting merging. Feel free to let me know if you need help.

I upgraded my home desktop to Ubuntu Breezy over the last day or so. Ran one major issue in that I needed to run dpkg-reconfigure xserver-xorg before I had X again after rebooting.

Apart from that everything seems to be much the same, the only really visible things I’ve noticed so far is usplash as the system boots (don’t know if it’s just me, but it makes it feel 10 times slower!) and Evolution has a new icon.

I’m quite pleased with Evolution in Breezy, mainly because it is Evolution 2.4 which contains the patches that I wrote to support inline signed and encrypted GPG messages. It’s always a nice warm fuzzy feeling when your code makes it into something useful.

A good paper from the Berkman Center for Internet and Society, covers Open Source in the bigger picture of things.

Get it from the link below.

Roadmap for Open Information and Communication Technologies (ICT) Ecosystems.

I’m currently in the process of adopting the Debian PHPwiki Package, which involves fixing a whole lot of bugs and upgrading to PHPwiki 1.3.10 (latest stable release).

1.3.10 changed some internal logic relating to URL handling so the old rewriting scheme no longer works. I’m trying to come up with a new all-singing, all-dancing configuration setup that will allow the package to work “out of the box” in the following 4 setups with as little modification to the default configuration files as possible (ie. as little use of sed/awk to insert config values as possible).

1. mod_rewrite enabled, installed in subdir, eg (http://www.example.org/phpwiki/HomePage)
2. mod_rewrite disabled, installed in subdir, eg (http://www.example.org/phpwiki/index.php/HomePage
3. mod_rewrite enabled, installed in root, eg (http://www.example.org/HomePage)
4. mod_rewrite disabled, installed in root, eg (http://www.example.org/index.php/HomePage

The PHPwiki source code is always installed in /usr/share/phpwiki/. The basic configuration that I’ve come up with is as follows:
apache.conf

<ifmodule mod_rewrite.c>
        RewriteEngine on
        RewriteRule /phpwikidata/(.*)$  /usr/share/phpwiki/$1   [L]
        RewriteRule <url>(.*)       /usr/share/phpwiki/index.php/$1  [L]
</ifmodule>

<ifmodule !mod_rewrite.c>
        Alias  <url>                 /usr/share/phpwiki/
        Alias /phpwikidata/         /usr/share/phpwiki/
</ifmodule>

<directory /usr/share/phpwiki/>
        DirectoryIndex index.php
        Options +FollowSymLinks
        AllowOverride None
        order allow,deny
        allow from all
</Directory>

config.ini

DATA_PATH = /phpwikidata
; Note following two are commented out
;USE_PATH_INFO = false
;VIRTUAL_PATH = /phpwiki

This configuration works perfectly for cases 1 and 2 listed above. It requires the apache config snippet to be generated by the postinst script (<url> is replaced with either ‘/phpwiki/’ or ‘/’), but the actual config.ini file does not need to be processed at all.

However this configuration does not work for cases 3 and 4 as PHPwiki seems to get confused as to where it is installed and starts linking to http://www.example.com//HomePage (double slash) which PHPwiki then interprets as the page ‘/HomePage’ which doesn’t exist. To combat this problem we can modify config.ini to specify the virtual path (or URL) that phpwiki appears at. For example:

config.ini

DATA_PATH = /phpwikidata
USE_PATH_INFO = true
VIRTUAL_PATH = <urlpath>

This configuration now works perfectly for cases 1 and 3 listed above, however it breaks cases 2 and 4. Additionally it requires us to process config.ini to replace the <urlpath> variable. This is bearable however as it is a simple subsitution.

So the summary of the problem is: using my current configuration, the USE_PATH_INFO and VIRTUAL_PATH directives must be present if mod_rewrite is enabled in apache, but must be absent otherwise. This is hard to detect in a postinst script, makes generating the config.ini file much more complex and will no doubt cause havoc with future upgrades.

Does anyone know of a better way that I can make all four scenarios above work with minimal (preferably none) modifications to config.ini?

If not, given that I’d prefer not to put logic into the postinst to detect mod_rewrite state I think I’ll make the package only support installing in a subdirectory and add a notice to the user (README.Debian or similar) telling them how to manually configure it for usage in the webroot. Would this be an acceptable fall back position?

Finally got around to writing an abstract for an LCA’06 paper tonight and got it submitted. I hadn’t realised the CFP was closing so early so it was a bit of a rush but I’m quite happy with how it turned out.

No idea if it will be accepted at this stage, but you can read it at the link below.

Linux for Broadband Rural Wireless, The CRCnet Experience

It’s fast coming up to that time of year again when WLUG has our annual general meeting and the committee that guides the LUG for the next year is elected. With only 2 weeks to go, and with just over 2 weeks behind us since the AGM announcement (and the accompanying call for nominations) there have only been 3 nominations for the 7 possible committee positions. All 3 nominations are existing committee members who are standing again, and I’ve not heard any suggestion that there are others considering standing either. Naturally this situation has led to people asking the question “Can WLUG survive” and “What happens if we don’t get a committee!”. I think this will be an interesting period for WLUG, it’s not entirely new, there were similar situations this time last year, however unlike then we seem to have run out of people who can be easily shoulder tapped this year. So is it all doom and gloom for WLUG? I’ll give you my opinion soon, but first lets look at how WLUG got to where it is today.

WLUG Formation
I can only really give an accurate history from 2001 onwards when I first became involved, however luckily I think that covers most of WLUG’s history, and certainly all of of the history of WLUG Inc.

The first WLUG meeting I attended was also the first WLUG meeting in quite a while from what I recall, it was at the old Bugger The Mortgage building at the
north end of Victoria St and was organised by Mark Jones? of BSD. The general aim of the meeting was to kickstart the LUG (again) and try and get some sort
of organisation into the meetings. From what I understand of before that time the LUG existed primarily as a mailing list, with occasional sporadic meetings. There was no official or even semi-official organisational structure.

My memory isn’t that great so I can’t really remember a lot of the detail that happened in 2001 after that, however eventually the consensus seemed to be that more structure would be good for WLUG and that an Incorporated Society would be the best way to achieve this. Daniel Lawson took on much of the hard work involved in bringing the society into being and laid many of the foundations for the success of WLUG over the next few years.

The inaugural committee was elected in Sep 2002 and several of its members continue to serve to this day as part of what I would call the “core” group of WLUG members.

Wlug Inc. 2002 - Present
It would be very hard to argue that WLUG Inc. hasn’t been successful over the past 3 years. The LUG has certainly grown from what it was and has developed
a number of exteremely useful resources, the cornerstone of which is undoubtedly the wiki. The credit for which is strongly owed to Perry Lorier. These resources are well known and I don’t think it is exagerating to say that WLUG is the most organised and well run LUG in the country. I think every month for the past 3 years (maybe with the exception of Dec/Jan) there has been an organised WLUG meeting, a big difference from the prior situation of ad-hoc meetings every now and again.

During this time much of the effort and work that has driven WLUG and achieved the successes has been contributed by the “core” group of WLUG members, (which I think can be loosely defined by those that have sat on the committee for more than a single term).

The LUG has successfully run several Installfests and the Unix Tutorials at the university over the past 3 years. Activites that were both designed to advertise the LUG and attract new members. However this is where WLUG has not succeeded well at all over the past 3 years. While the LUG has certainly grown somewhat, I feel that we’ve failed to develop active membership within the LUG. We have a strong group of people that attend the meetings each month, and participate on the mailing list, but a real lack of volunteers to do the actual work of running and developing the LUG.

This certainly isn’t intended as an attack on any existing members of the LUG, including those that have joined over the past couple of years, or any of the
commitee members who have contributed to the LUG during that time. By and large, I think everyone has committed as much as could be expected to the LUG, however those commitments do naturally come to an end. Of the “core” group who have been leading the LUG for the past few years there are a number of people who are stepping down from the Committee or a no longer available to stand for a variety of reasons. Some are moving (or have moved) away from Hamilton, others simply don’t have the enthusiasm for the LUG any more. However the contribution these individuals have made to the early development of the LUG is significant and I’m sure that even as they scale back their organisational involvement they will still retain an interest in the general LUG workings. Of those “core” members who are still involved and are standing again, it would be silly of us as a LUG to assume that will always be the case.

My Diagnosis
I think a recent series of discussions within the Linux Australia community nicely summarises the situation WLUG is facing. While some of the comments are only applicable to the larger Linux AU organisation, I think we can certainly take many of the points about needing to ensure that the organisation has sustainability and avoids burn out of it’s Committee to heart. Hindsight is certainly a wonderful thing and it’s easy to see now that we have badly neglected the important aspect of ensuring there are new LUG members committed to continuing it’s development as the current “core” group needs a break or moves on.

Conclusion
Hopefully most of you will have recognised that the title of the entry is actually a rhetorical question. I think it’s a fact that WLUG will continue to exist providing many of the same resources as it does now, there is too much capital invested in it for it to be left to die. The real question then becomes how does WLUG address the problem of sustainability and ensure that we have a full committee for the upcoming year and the years following that.

I think that question is also directly applicable to NZOSS and is something we need to consider carefully as we push for the formation of a Linux NZ type organisation.

I’m not going to propose a solution to these issues right now, a) because I don’t have one yet, and b) because it’s 20 to 1am, I’ve just spent two hours writing down these thoughts and I have to go to work tommorrow morning.

As a final point I think it is worth asking some hard questions of ourselves, such as:

• Does Hamilton have a big enough user base to support a LUG like WLUG without burning out a small group of key individuals?
• What could we have done differently to have had a new committee ready to be nominated and take over?

Perhaps the answer is that WLUG Inc. should be scaled back and toned down. Perhaps the solution to the problem actually lies in NZOSS and LinuxNZ integrating closely with smaller LUGS. I don’t know the answer yet but we should definitely think about all our options.

I am certain that WLUG will survive however, one way or another.