Ubuntu Traffic Benjamin Mako Hill

Welcome to the sixth edition of Ubuntu Traffic. This issue covers the week of September 25 - October 1 in 2004. Ubuntu Traffic summarizes the most important mailing list and IRC discussions involving the Ubuntu GNU/Linux distribution.

It seemed that it would be hard to keep up the momentum that we had going in the last two weeks but we've done it! With more than 1400 messages clocked in this week, we're keeping up an intense pace. Work on the distribution is moving forward. Bugs are being reported and fixed, and some important governance foundation is being laid. Lets all keep up the good work!

You can sign up for any of the lists summarized here at http://lists.ubuntu.com. Please join in!

Bits and pieces that didn't get a full story but are worth mentioning include:

  • Responding to Traffic, Ben Lisle asked if there was plans for a planet.ubuntulinux.org in the style of planet.debian.org. In a word, yes. A planet (an aggregation of blogs from people involved in a project) is available at http://planet.ubuntulinux.org
  • Jonathan Riddell announced that he had the beginning of KDE 3.3 packages for Ubuntu based on the Debian unstable packages online saying, "It's just kdelibs and kdebase for now, hopefully I can look at making other packages soon. Contact me if you want to help." Use the following line in your sources.list to enjoy them: 
    deb http://geeksoc.org/~jr/ubuntu/ unstable main
  • Matthias Klose suggested that, "Some packages need additional language packages for complete localization support (mostly openoffice). could we add dependency packages on the CD, which add these packages on request, i.e. ubuntu-desktop-de-de, providing ubuntu-desktop, depending on additional packages, i.e. openoffice.org-help-de, openoffice.org-l10n-de?" Matt Zimmerman announced that we would be tracking this in https://bugzilla.ubuntu.com/show_bug.cgi?id=1760
  • Sivan Green suggested that, "as I myself still feel overwhelmed by the amount of background and the specifics this project involves, I'd like to start the "Ubuntu Technical Docs" e.g. , docs for developers and wannabe's (like me :-) ) I believe this can be a good way to document most if not all the work that take place on ubuntu, as well as establish a common ground for development information exchange. Take for example when someone needs to make a new installer cd to test something, he should be able to consult this repository to accomplish his task, instead of asking the person in charge." Sounds like a great idea Sivan!
  • There were a couple suggestions for GNU Cash posted to Ubuntu. Matt Zimmerman worked a little bit of sync magic and it should now be available in universe.

Matt Zimmerman pointed to http://bugzilla.ubuntu.com/show_bug.cgi?id=1644 and said:

Requests that pptp-linux be available on the CD, since it is required for some users to get access to their ISP. pptp-linux is currently in the SupportedSeed.

Shall we add it to BaseSeed, or only to ShipSeed?

Looking at the package, it is very simple, essentially just supplying /usr/sbin/pptp. As such, it should be quite safe. We currently include ppp, pppoeconf, etc. in the BaseSeed with similar justifications. However, PPTP is not as commonly needed, and perhaps ShipSeed is sufficient.

There was not an overwhelming opinion either way except that this tool, and others like it, should be on the CD. In that thread, Matt later said, We currently do not have isdnutils on the CD. It's no problem to add it; what other tools should be present on the CD to have reasonable greatest-common-factor ISDN support?> Michael Vogt replied saying, I had to install "pppdcapiplugin" and "isdnutils" to get isdn working. Making it work was a bit tricky, the modules need to be inserted in the right order (at least for my card). Matthias Klose followed up elsewhere saying that, if we add it, please sync isdnutils again from unstable/testing.

Matt Zimmerman started another thread with the following summary of an IRC conversation on a problem relating to Ubuntu sounds:

A brief IRC discussion started about this due to ubuntu-sounds. Currently, no one has ubuntu-sounds installed, and it's not entirely appropriate for an existing package to depend on it, so users who are upgrading will not get the sounds. This is either a bug or a feature.

Considering it a bug, there are some possible solutions:

  • Add a script to ubuntu-base, of the sort which would be used as part of the woody->warty upgrade process, which lets the user say "give me the current ubuntu desktop stuff", and does so
  • Create an ubuntu-desktop metapackage which depends on everything in the DesktopSeed, so that when it is upgraded, new packages are installed. This is particularly nice because of the change semantics: if the user removes one of the desktop packages, ubuntu-desktop is uninstalled, and the user's changes are preserved. So, users who accept the default package selection get new ones automatically, and others are left alone.

Both ideas has support from people on the list. Thom May argued that, I like the latter solution - it also allows for clearer instructions when upgrading from woody. Rather than "aptitude install ~tubuntu-desktop" or whatever, just "front-end-of-choice install ubuntu-desktop". Sebastien Bacher agreed with Thom. Scott James Remnant and Sivan Green like the first option.

Matt Zimmerman followed up later in the week with more information saying:

So I put together a little metapackage generator for ubuntu-base and ubuntu-desktop, which works off of the Packages files, and it seems to produce reasonable output. I received a couple of new DesktopSeed additions that I didn't realize I was missing.

I got to wondering, though, whether this is the right implementation. Currently it depends on everything in Desktop. So, if the user decides to remove anything in Desktop, it gets removed, and they go into "manual mode".

I'm debating whether or not it should depend only on seeded packages, allowing the user to swap dependencies if they prefer (e.g., libesd-alsa0 for libesd0). This would also help the package to stay around during partial upgrades.

On one hand, I like having it depend on the complete, official desktop set, because it ensures a certain level of consistency (Provides being the primary exception). On the other hand, it means that it'll be uninstalled more often, and so less useful.

Matt also asked for opinions. Getting back to the argument in question, Martin Pitt asked, So what should be the purpose of such a desktop metapackage? As I understood it, it shall make it easy to setup a standard Warty installation on an e. g. woody system. But this is equally easy with installing the desktop task with aptitude. Matt Zimmerman replied saying, As I explained in the previous thread, its purpose is to provide smooth upgrades. If we add a new package to the desktop seed for Hoary, users upgrading from Warty should receive it as well.

Jeff Waugh announced to the ubuntu-users list:

I wrote a hacky little script last night to tell me what I had installed from universe, so I knew which pieces I'd have to keep when it broke. ;)

It's a useful little script on its own, but if you'd like to send me the results, we might be able to find some common things that should live in SupportedSeed.

Just mail the output to: jeff.waugh+universe@canonical.com

The script includes the following text:

#!/bin/sh
(awk '/^Package:/ { print $2 }' /var/lib/apt/lists/*universe*Packages ; dpkg --get-selections | awk '/install$/ { print $1 }') | sort | uniq -d

Matthias Klose posted a report from some of his experimentations with spell checking in warty:

Wondered why spell checking was said to be not working warty, took me a while finding out that it works for German and French, but not English. Spell checking support is provided by:

  • ispell - the "old" package
  • aspell - ispell successor, with 0.51 it is said to be a replacement for ispell (warty at 0.50).
  • myspel - better cross platform (Win/Mac) support, said to be faster.

Every spell checker needs a language specific dictionary, which are available in separate packages, sometimes the same source package provides language dictionaries for all spell checkers, they are not packaged in a uniform way.

On the desktop warty currently has the following applications using spell checking features:

  • OpenOffice (myspell)
  • Evolution (gnome-spell -> aspell)
  • Mozilla (myspell)
  • Abiword (gnome-spell -> aspell)

To add english spell checking support for warty

  • add from unstable (not yet in warty/universe):
    • aspell-en
    • openoffice.org-dictionaries
  • add to the desktop:
    • aspell-en
    • myspell-en-gb
    • myspell-en-us
    • openoffice.org-hyphenation-en-gb
    • openoffice.org-hyphenation-en-us
    • ibritish
    • iamerican

To add German spell checking support:

  • add to the desktop:
    • aspell-de
    • myspell-de-de
    • openoffice.org-hyphenation-de
    • ingerman

To be continued for other languages ... Spellchecking support for more than one language makes sense even without having the language support for this language, so maybe spellcheck support for the big languages in woody could be added.

This looks like there are only two spellcheckers to support in warty, aspell and myspell, which is good news. Thanks for the work Matthias!

In response to a rash of suggestions Jeff Waugh announced that there were now lists for Ubuntu in three different languages:

Due to popular demand, there are new lists available for discussion in German, Spanish and French.

There are already some new IRC channels sprouting up, like #ubuntu-es on freenode, and very soon we'll have translatable web pages and wiki! Woo!

Wouldn't it be great if traffic were also translated into a bunch of languages... Hmm.

Benjamin Mako Hill sent a message to the list about Community Council (the Ubuntu governance team) and its first meeting. I've included most of the report full text in here. It's here both to make the process more transparent and to maybe encourage some of you to get involved in the project decision-making and governance:

Today, the Ubuntu Community Council held its first meeting. More information on the council is on the website: http://www.ubuntulinux.org/community/council/

The agenda included the two (broad) items:

  • Team structures, leaders, goals.
  • Finalization of Ubuntu community structures and processes documents

Teams: Which Teams

More information on teams in general can be found here:

http://www.ubuntulinux.org/community/teams

The following new teams were discussed:

  • IA64 Team (already listed)
  • Security Team (approved)
  • Documentation Team (approved)
  • Internationalization/Localization/Translation Team (approved)
  • External Relations Team (on hold)
  • Accessibility Team (tentatively approved)

Team Process

Team leader should provide text for their team website with a small list of information on contacting and getting involved and on the goals of the team. Highlighting active members on the page as a way of raising recognition was also suggestion.

In terms of communication channels, all teams should begin with conversation on the standard devel channel (#ubuntu-devel) and on the standard Ubuntu list (ubuntu-devel). For mailing list conversation, teams should prefix team related information with [teamname] in the subject. When traffic for team becomes distracting or high enough volume, those teams can request or be requested to move to their own mailing lists. The default behavior should be to have traffic on the standard mailing list until it becomes unreasonable or difficult.

Community Council

Several people including Daniel Stone suggested that the council was too small and needed non-Canonical representation. Mark will work on finding and appointing a non-Canonical representative soon.

Appointments will be made by the SABDFL (Mark Shuttleworth) but, as decided at the meeting, will be confirmed by the maintainers. Terms will be for 2 years.

The current board will be run by the current maintainers and then, in one year once the community process is more mature, the board will be confirmed again more formally in a special case confirmation.

The relationship between the Technical Board and the Community Council was discussed. The consensus was that the two will not have purview over the same issues often and will disagree rarely as well. In those rare cases, it decisions or decisions about jurisdiction will have to be made by the SABDFL.

Maintainers, defined on the website, are currently limited to developers who have been working on Ubuntu full-time and Herbert Xu. Over time, this will expand according to the process online.

Maintainers

The board discussed the maintainer process. The feeling was that maintainers will be confirmed by the Community Council but only with approval by the Technical Board.

Maintainership will be permanent but will have to be renewed every two years through a simple process. This aims to cut down on missing in action and inactive maintainers. Retirement will be encouraged and reactivation of maintainership will be allowed.

In terms of keeping maintainers in the loop on important policy changes and such, the group agreed on an ubuntu-devel-announce that all will be very low traffic and that all Ubuntu maintainers will be expected to read. Changes in policy will be posted to this list.

Colin Watson was careful to state that, "I think we should be clear up-front that you don't have to be an Ubuntu maintainer to contribute; you can contribute patches just as easily by making branches and requesting merges."

Benjamin Mako Hill had some clarifications about website language which he was encouraged to clean up himself.

Getting Involved

To get involved with the next CC meeting in two weeks, you can:

I hope to see a few of you at the next meeting.

Thibaut Varene filled in the list on his progress on the IA64 port which was discussed briefly on the list in the previous week saying: I've now completed "stage1" (which was building warty main from debian snapshot) and I'm starting "stage2" (which is building warty main from warty). stage1 was quite wicked, definitely non-trivial that is, and I shall thank LaMont for his great support:) I'll be working on d-i as of next week, most likely. Side note: I've been running the same process on hppa (for fun) and it's there: stage1 is over, stage2 about to begin.

Great work to T-Bone and everyone else who is helping! Keep it up and and keep us informed.