Ubuntu Traffic #21 For 2005/01/14

By Benjamin Mako Hill

Table Of Contents

Introduction

Welcome to the twenty-first edition of Ubuntu Traffic. This issue covers the second week of the new year: January 8 - 14, 2005. Ubuntu Traffic summarizes the most important mailing list and IRC discussions involving the Ubuntu GNU/Linux distribution.

Ubuntu Traffic can be found on the web at http://people.ubuntulinux.org/~mako/ubuntu-traffic/. You can also receive in text form over email by signing up for the Ubuntu News mailing list at http://lists.ubuntu.com/mailman/listinfo/ubuntu-news. There is now an RSS feed for traffic available as well! You can find information on turning that on at the Ubuntu Hompage (http://people.ubuntulinux.org/~mako/ubuntu-traffic/) .

You can sign up for any of the mailing lists summarized here at http://lists.ubuntu.com. You can also join the IRC discussion summarized here in #ubuntu and other channels on the Freenode network: irc.freenode.net. Please join in and maybe you will be featured in the next traffic!

First, the following bits and pieces didn't get a full story but are worth mentioning:

Mailing List Stats For This Week

We looked at 1543 posts in 6560K.

There were 456 different contributors. 225 posted more than once. 328 posted last week too.

The top posters of the week were:

 

1. Handling Metapackages
2004/12/20 - 2005/01/09 (10 posts) Subject: "meta packages for ubuntu-desktop"
People: Lex Hider, Matt Zimmerman

Lex Hider kicked off a long-running thread on the ubuntu-devel list suggesting that the big two metapackages in Ubuntu be split. Started last month, the thread ended this week:

The 2 big meta packages (ubuntu-desktop and ubuntu-base) are very handy for easy installing and upgrading ubuntu. However it's not completely easy to choose only parts of the ubuntu-desktop packages. e.g. I want to just install gnome from ubuntu-desktop.

If you check out the seed at http://people.ubuntu.com/~cjwatson/seeds/hoary/desktop you'll see that it's divided into headings like: printing, fonts, desktop gnome fonts, gstreamer, python.

I'd like to suggest that instead of ubuntu-desktop depending on ~100 packs, it depends on a couple of meta packages to ease both maintainership and installing. We don't have to go overboard with this, but a couple of these I think would be a good idea.

e.g. all the python stuff can go into something like ubuntu-desktop-python or ubuntu-python and the gnome stuff into a similar package that ubuntu-desktop would depend on. So ubuntu-desktop could depend on ubuntu-desktop-python (you can call it whatever you think is a good name, just an example).

Dawynn replied with an very enthusiastic message in support as well as did several others on the list. Matt Zimmerman replied saying:

The original idea of these packages was to represent the seeds, and thereby ease upgrading when the seeds change. I'm a bit wary of creating a tree of metapackages as a means of high-level package selection; this was found to be suboptimal in Debian in the past.

Maybe we should take a step back, describe the use case, and consider alternative technical solutions to satisfy it.

Later in the thread, Matt Zimmerman voiced a few more concrete objections to the idea saying:

The guiding principle should be "KISS". In the common case, users should not even be aware of these metapackages; they're a background mechanism for keeping the package selection up-to-date. Users shouldn't generally install or remove them unless they know exactly what they want, in which case they can manage their own package selections.

Currently, we offer two options:

  • use the default package selection (and optionally add to it), receiving automatic updates to the default selection when they occur
  • manage your own package selection, and take responsibility for keeping up with changes yourself (by reading release notes, mailing lists, checking the metapackages by hand, etc.)

What you're proposing is a third option, positioned between these two. So far, I'm not convinced that the trade-off is in our favour: complexity (in the packaging system and for the user) versus providing some users with a "halfway" option for managing package selections.

 

2. Installing From Live CDs
2005/01/02 - 2005/01/12 (4 posts) Subject: "Live/Install CDs"
People: John Richard Moser, Matt Zimmerman, Colin Watson, Paul Sladen

John Richard Moser kicked off a thread on ubuntu-devel with two separate ideas about installing from Live CDs:

Why not package Live CDs with an extra Net-Install boot menu option and a Net-Install Gnome GUI frontend? For those of us wanting Live CDs, an extra couple megs (10-20?) won't matter; for those of us installing, an install from net is usually sufficient.

I think this would be nice as well because you could have a special install-to-GUI mode to get up while still installing. In this mode, you go as far as to partition the disk, select mount points, and create a user. Then /home is mounted, and the installer exits.

Once this is done, the Live CD could have a copy of the user account created in the Live CD /etc/passwd. The user would then get pushed into the Live CD (X/Gnome). A gnome-session wrapper (or whatever is appropriate) would detect if this was being done, and would additionally start up the installer using a Gnome interface (doesn't Debconf allow this?) and pick up where it left off.

Once the user is done using the GUI installer to the point that it's downloading and unpacking packages, he can switch desktops and do something in a fully functional Ubuntu environment while Ubuntu installs. He'll be working directly on what will become his /home directory, so it's like Ubuntu is already installed.

When the installation is finished, the user can reboot into his new system. Optionally, all installation tasks could be completed from the Live CD so that a reboot wouldn't require 10 minutes of waiting.

Matt Zimmerman replied to John's first idea (about putting the net-installer on the Live CD) saying, "This is a good idea, and something we discussed back at the Oxford conference, but currently we don't have a GNOME GUI installer to plug into it (and it's too late in the release cycle to begin developing one), so this is something to look at for the release which follows Hoary. If you're interested in participating in its development, contact me."

I'm sure Matt's offer is one that is open to anyone who wants to get involved on this. Colin Watson replied saying, "I intend to try to do this, but it requires a bit of anna work." Finally, Paul Sladen followed up in this thread saying, "The other thing I'd like to see is an option (on the install CD), is to act as a 'netboot server'. An equally small setup containing an automatically- configured DHCP, TFTP & NFS server for doing an initially PXE bootstrap to another (CD-less laptop) machine with a back-to-back/cross-over cable."

 

3. Supporting Autorun
2005/01/04 - 2005/01/14 (59 posts) Subject: "Shall we support the autorun feature?"
People: Martin Pitt

In a long thread, Martin Pitt opened the discussion on the support of autorun by saying:

Bug #1956 deserves a public discussion, so let's do that here.

Gnome proper offers a so-called "autorun" feature for removable media. If enabled in gnome-volume-manager (disabled by default), g-v-m checks if a file "autorun" or "autorun.sh" is present and executable on newly mounted media. If so, the file is automatically executed.

However, since pmount mounts non-fstab drives with "noexec", this currently fails. So the question arises what we want to do with autorun in the future. I see the following options:

  1. Completely disable: pmount with noexec (as now), remove the configuration option from gvm
  2. enable: pmount with exec (should work automatically then)
  3. enable with confirmation dialog: pmount with exec, change g-v-m to confirm execution

I don't really like 3 because confirmation dialogs tend to get ignored and they do not tell you what exactly will be performed anyway. I doubt that many users would want to actually read the shell code (let alone analyze a binary) before executing it.

My personal preference is option 1.

It should be noted that our only use case so far - automatic Ubuntu CD upgrades - does not need this feature. This was solved by a HAL script that checks whether an inserted CD is an Ubuntu one.

Many people spoke up for a number of different positions. In addition to people echoing Martin's preference for the first option, many people suggested that we needed some sort of mixture between 1 and 2 and that we needed to special-case the Hoary CD for an automatic option to upgrade.

Martin summarized the conclusions of the thread saying:

Thanks for the numerous replies to the discussion.

It seems that we should not completely drop this feature, but it should default to "off" in any case.

I recently tried this out again, Gnome already shows a confirmation dialog before executing the autorun file. So for maximum upstream compatibility I will implement option 3.

I will modify pmount soon to have a new switch -e/--exec which mounts a device with the 'exec' flag. Also, I will modify gnome-volume-manager to pmount with -e if the autorun feature is enabled.

 

4. Experimental Hoary Live CD
2005/01/05 - 2005/01/12 (19 posts) Subject: "Experimental Hoary live CD available for testing"
People: Matt Zimmerman

Matt Zimmerman posted to the list announcing a new experimental live CD and asking for feedback:

Andreas and I spent some time hacking on the live CD today, and it's starting to come together. As many of you know, we've redesigned the live CD from scratch for Hoary, to simplify maintenance and to provide a base for some interesting new features. Here's what works so far:

  • Boot into d-i
  • Set up the live filesystem
  • Pivot into the live filesystem
  • Create a user
  • Configure GDM autologin
  • Initiate a normal boot sequence
  • Login as root (no password)

You'll find that it looks very much like a normal Ubuntu system (more so than the Warty live CD), and this is intentional. Whereas the old live CD used infrastructure derived from other live CD projects, the new design uses infrastructure from existing Ubuntu components (for example, for hardware detection), along with some completely new ideas.

Things which aren't finished yet include:

  • There isn't much progress indication yet, and in some cases you may see a blue screen during much of the boot process. If you are seeing a blue or red screen for too long, switch virtual consoles with Alt+F1 and Alt+F2. This will be fixed.

  • There is as yet no means to automatically generate a working X configuration. Daniel Stone is working on this. Currently, GDM startup is suppressed and the boot process ends with a text console login. If you'd like to try out a desktop session, run:

    dpkg-reconfigure xserver-xorg

    and answer the questions, then run /etc/init.d/gdm start

    I ran into a problem once where I needed to unload and reload the mousedev module in order to get the mouse working, but I haven't looked into it yet.

  • The boot process asks a few too many questions. This will be fine-tuned as things proceed.

Get it here: http://people.ubuntu.com/~mdz/ubuntu-live/hoary-live-i386-alpha1.iso

and follow up here to let us know how it's working for you. It's based on a Hoary snapshot which was built by Andreas about one week ago, but we should be able to build daily images fairly soon.

Folks caught a number of bugs and errors on the CD which Matt and Andreas were quick to fix.

 

5. ISDN Support
2005/01/09 - 2005/01/11 (9 posts) Subject: "Adding ISDN drivers (AVM Fritz) to lrm"
People: Matthias Klose

Matthias Klose posted to the devel list to announce that he'd made a big step forward in regards to ISDN support in Hoary saying, "The added ISDN drivers and firmware for various AVM Fritz cards increase the lrm modules "a bit". Each one of the 10 modules varies between 600k and 850k, adding firmware (300k - 1200k). The current modules can be found at http://people.ubuntu.com/~doko/lrm/. If these modules should be separated in their own packages, how should these be called? Of course the packages are built from the same source, so you do have to build no more packages."

Matt Zimmerman asked what the total increase in the size of debs and the source package. Matthias replied saying, "source about 6MB, debs about 3MB for each module package built on i386, plus the firmware package (1,3MB), and the avm-fritz-kernel-source package (3,4MB). debs size increase in total about 20MB. the source tarball is currently added as a uuencoded tarball to the diff."

 

6. Interactive Upgrade Hooks
2005/01/10 - 2005/01/12 (9 posts) Subject: "Interactive upgrade hooks"
People: Matt Zimmerman, Colin Watson, Michael Vogt

Matt Zimmerman sent a message to the list with a link to http://www.ubuntulinux.org/wiki/InteractiveUpgradeHooks where there is a good discussion of the need for interactive upgrade hooks:

After certain upgrades (most notably upgrades between Ubuntu releases), there are follow-up actions which should be taken by the user. These are not logically part of the upgrade, but should be dealt with at some point after the upgrade is complete.

A prime example is the UTFEightMigrationTool. During an upgrade from Warty Warthog to Hoary Hedgehog, the system will be configured such that UTF-8 encoding is available, and will be expected by applications per default. The user should switch to a UTF-8 locale, and possibly rename or re-encode files in order to achieve the best user experience. These things cannot be done in automated fashion during the upgrade, but must instead be dealt with interactively by the user.

Original Proposed Design

  • Maintainer scripts invoke a program to register a hook (typically a shell script) to be run by the user
  • update-notifier receives these registrations, and notifies the user that they are pending
  • When the user elects to process pending actions, they are executed in sequence within the context of the desktop (and so can display a GUI, interact with the user, etc.)

Colin Watson replied saying, "update-notifier is quite high up in our stack; it's in the desktop, not in base, and it's a graphical program which may not be running at the time of the upgrade. Can I suggest that something in base should receive the hook registrations instead, and update-notifier should read the registrations from that? Ideally it should be possible for an interested user to run something on shell login that deals with pending registrations without having to have any of the desktop installed beyond what's needed to process the actions. (If you actually meant that update-notifier should read the list of registrations out of somewhere in the packaging system, then we're probably talking about the same thing in different language.)" Matt clarified that this was what he meant.

Michael Vogt replied saying, "Tollef and I designed a proposed spec and put it on the wiki. Feedback is very welcome. A format for the hook file is suggested (closely modeled after debconf so that we can use some of there tools, e.g. debconf2pot) and a basic concept how it can be added to update-notifier. The "post-upgrade hook was run" information will be put in a format that is easy to use by text-based tools as well. The idea is that it should be easy to write a tool that tells the user about the "post-upgrade hooks" and possibly about updates too (as Colin suggested)."

The spec included:

Design Spec

  • the directory /var/lib/update-notifier/user.d/ is used to store hooks
  • a hook file looks follows rfc822 rules:
    • a fieldname may have a "-$locale" in it. This is for i18n.
    • each hook must have a unique "Name" key and a "Description" key
    • a optional "Priority" with critical, high, medium, low that gives the user a idea how important the hook is
    • a optional "Command" field may be registered with a shell-command that the user can run (e.g. a script in /usr/lib/update-notifier/user.d/)
    • a optional "Terminal: True" field if the command should be execute in a terminal
  • update-notifier will use gamin to scan /var/lib/update-notifier/user.d/ and show a small information icon for hooks it has not seen yet
  • when the user clicks on the icon the name and description is given. If a shell script is registered, it asks if it should run that script.
  • the encoding of the i18n fields is UTF-8

Status

  • Basic support implemented in update-notifier 0.38
  • Missing: i18n (-$locale), mtime check of the hook file

Example:

Name: The great UTF-8 Migration
Name-fr: Le grande UTF-8 Migrationé
Name-de_DE: Die große UTF-8 Migration
Priority: Medium
Command: bc
Terminal: True
Description: This command will convert your stuff into UTF-8.
 Use this command if you want a working gnome desktop and you
 feel the world should be a better place.

 

7. Community Council Meeting
2005/01/12 (1 post) Subject: "Community Council 2005-01-11 [ + Local Teams and Universe ]"
People: Benjamin Mako Hill

Benjamin Mako Hill posted a message to the Ubuntu-News list (http://lists.ubuntu.com/listinfo/ubuntu-news/) (which you should sign up for now if you haven't already) with the summary of the latest Ubuntu community council meeting. Mako said:

I've just finished writing up the summary of this Tuesday's (January 11, 2005) meeting of the Ubuntu Community Council. Information is available here:

Meeting on January 11, 2005:

The meeting covered a number of issues but there are two major issues which are of particularly noteworthy:

  • The Council talked about new Local Community Teams (previously called Country Teams and now called LoCo Teams for short) for promotion of Ubuntu in particular locales. Folks wanting to get involved should read the log of the meeting and get in touch with Matthias Urlichs <smurf@smurf.noris.de (mailto:smurf@smurf.noris.de) > and myself.
  • The council talked about the need to get community members involved in a contributing to and maintaining pieces of Universe. There is more information on this in the log and what to do if you'd like to get involved in Ubuntu in this way.

 

8. Documentation Team Happenings
2005/01/03 - 2005/01/17 (30 posts) Subject: "Architecture-specific docs"
People: John Levin, Sean Wheller

On the ubuntu-doc list, John Levin posted to ask people about architecture specific documentation saying:

What do people think of having architecture-specific sections on the wiki? At the moment, there doesn't seem to be a PPC section (gathering together, e.g., one-button mice, mac on Linux, yaboot etc) or an AMD64 section. It would be easier for

Developing from this, what of having a version of ubuntu-in-a-nutshell tailored for PPC users? It shouldn't require too much work - much of the material can simply be reused without any changes - but would help with clarity and relevance.

Sean Wheller responded to say, "Based on your message I have included architecture specific sections in the Ubuntu Administration Guide. I don't know about the wiki, but if somebody wants to write them in wiki, I will be glad to move the content to DocBook for them."

Elsewhere, Sean made a comment about licensing of Ubuntu documentation saying, "I have added a section "Our Documentation License" to https://www.ubuntulinux.org/wiki/AboutTheUbuntuCoreDocumentationProject"

Finally, in another thread, Sean Wheller also announced that he made a commit to the subversion repository with the beginnings of the admin guide to kick off that project. Great work guys and thanks for all your hard work this week Sean!

 

9. Ubuntu Security Notifications
2005/01/09 - 2005/01/14 (4 posts) Subject: "[USN-57-1] Linux kernel vulnerabilities"

Martin Pitt posted another weeks worth of Ubuntu Security Notification to the list notifying folks of another rash of bugs and pointing to their fixes. These included the following:

linux-source-2.6.8.1 vulnerabilities

Ubuntu Security Notice USN-57-1 (CAN-2004-1235, CAN-2004-1337)

Affected Release: Ubuntu 4.10 (Warty Warthog)

Affected Packages Are:

Fix: The problem can be corrected by upgrading the affected package to version 2.6.8.1-16.8. In general, a standard system upgrade is sufficient to effect the necessary changes.

More Information: http://lists.ubuntu.com/archives/ubuntu-security-announce/2005-January/000059.html

krb5 vulnerability

Ubuntu Security Notice USN-58-1 (CAN-2004-1189)

Affected Release: Ubuntu 4.10 (Warty Warthog)

Affected Packages Are:

Fix: The problem can be corrected by upgrading the affected package to version 1.3.4-3ubuntu0.1. In general, a standard system upgrade is sufficient to effect the necessary changes.

More Information: http://lists.ubuntu.com/archives/ubuntu-security-announce/2005-January/000060.html

mailman vulnerabilities

Ubuntu Security Notice USN-59-1 (CAN-2004-1177)

Affected Release: Ubuntu 4.10 (Warty Warthog)

Affected Packages Are: mailman

Fix: The problem can be corrected by upgrading the affected package to version 2.1.5-1ubuntu2.2. In general, a standard system upgrade is sufficient to effect the necessary changes.

More Information: http://lists.ubuntu.com/archives/ubuntu-security-announce/2005-January/000061.html

linux-source-2.6.8.1 vulnerabilities

Ubuntu Security Notice USN-60-0 (CAN-2005-0001)

Affected Release: Ubuntu 4.10 (Warty Warthog)

Affected Packages Are:

Fix: The problem can be corrected by upgrading the affected package to version 2.6.8.1-16.10. In general, a standard system upgrade is sufficient to effect the necessary changes.

More Information: http://lists.ubuntu.com/archives/ubuntu-security-announce/2005-January/000062.html

 

 

 

 

 

 

We Hope You Enjoy Ubuntu Traffic
 

Ubuntu Traffic is created and produced by Canonical Ltd. All pages are copyright Canonical.