Michael Vogt has implemented a system for asking this type of question in a nice way, see InteractiveUpgradeHooks in the wiki.

There will already be such a hook for the UTF-8 transition, which will include changing the system default locale (UTFEightMigrationTool).

In other words, I think everything is in order, and language packs do not need to worry about which locale is chosen by the user. It should be simple and sensible, though, for them to cause the appropriate locales to be generated when they are installed, so that the user can select them if desired.

Sure, this is pretty simple to do.

Assuming that the kernels are binary-compatible, just copy vmlinuz into /install. If you need additional modules, you can add them to the initrd.

If the kernels are not binary-compatible, you'll also need to replace the module udebs on the CD with new ones, and regenerate the Packages and Release files, but it's still fairly straightforward.

Again, I think we need more mailing-lists. Ubuntu-devel has become the default target for almost any kind of mails, hopefully dealing with "something related to Ubuntu" (ranging from user-support, to real development issues), which ends up in a "topic mess". I tend to wonder "WTH is this mailing list about?" :P

I've suggested to Mako that we need a u-private mailing-list (or call it u-maintainers), a la debian-private, that is to say a low traffic mailing list that every Ubuntu Maintainer (and only them) has to be subscribed to.

A u-project m-l would certainly be helpful too, to discuss openings and new projects in Ubuntu, such as this mail requesting more mailing-lists, which I am sending reluctantly to u-devel, even more given the fact I'm no longer subscribed: I suspect that it'll be moderated :P

In practice a lot gets done on IRC; the latency is so much lower that it's worthwhile. A good deal has been done face-to-face at conferences, too.

In the early days, before we went public, development took place on the main Canonical internal mailing list (which now sees very few mails, and none about Ubuntu development), but the level of mailing list traffic was a good deal lower then than it is now. You can get a lot done if you give people tasks they're interested in and the freedom to get on with them largely unobstructed.

Any plans to use autopackage (autopackage.org) which would solve most, if not all, Linux install problems (distro-neutral packages, automatic dependency resolution with no central dependency database, IIRC, beautiful GUI for both GTK and QT, etc etc).

I don't want to argue on apt-get. It's a nice solution... for now.

I'll just cover some brief points why apt-get ain't no good for 'big market share use':

1. There will be too much software for a central repo to handle and test it. You'd need a petabyte just to store games from the last few years, on Windows at least.
2. Software makers could have their own repos, but that has more problems - the fact you have loads of conflicting repos in your sources.list and you are distro-specific.

So basically, for commercial (or even 'easy' non-commercial) software installation, apt-get is a 'sorta-works-but-will-break-in-the-future' solution. If you say that 'we' don't need commercial software, you are kidding yourself. Games for example could never be IMO non-commercial, unless we all paid a $35/mo subscription fee to play them but the original game is free. Or something. Just think that in a game it's probably 10% useful-to-other-projects code and 90% artwork, modeling, sounds which is going to be almost always 'game specific'

Anyway, any chance we could have autopackage soon? They are API stable now and they have some great packages for very hard to install stuff.

Q: Can I use autopackage for my new distro?

A: No, see the question below for more details, but essentially autopackage is not a tool for building distributions. It's a tool for 3rd party software developers to produce packages for their website that any Linux user can use.

I'm the autopackage maintainer. Just in case things get out of hand, let's clear up a few points:

• autopackage will not solve all Linux software install problems. Sorry. Popular misconception, even though we try hard to avoid people getting that impression on the website. It is only one component of a much larger set of work needed for that.
• Right now we don't have a 1.0 release, I think it'd make sense to wait until we do before trying to get the base release into any distributions.
• autopackage isn't just for proprietary software, in fact right now it's being used primarily by GTK+ based open source projects like GAIM and Inkscape.
• Yes, it does make sense to have the runtime in distributions by default, because otherwise when you first use a .package file you have to jump through hoops to switch on the +x bit, wait while the runtime is downloaded and so on. Having it all in the base distro avoids that (until we release a new version that packages start relying on that is ...)

There is a more comprehensive discussion of the pros/cons of centralised packaging here: http://autopackage.org/NOTES

We don't see it as a replacement for apt, rather it's complementary to it. Apt works great for managing the core of a distribution. It works rather less well when you try and scale it up to "everything you might ever want". It's been attempted many times before, with Debian, Gentoo and Fedora most notably, and it's inevitably ended up in a quagmire.

In my most humble opinion, the Ubuntu project would be better off concentrating resources and manpower on building a great operating system rather than a big collection of packages.

As a basis for USplash, we will need to start enabling the kernel framebuffer in the initrd, if (and only if) the 'splash' option is passed on the kernel command line (it is by default).

In the long term, this should probably be done by an initrd hook in the usplash package, but in order to weed out any hardware difficulties early, we should start doing this now, even before USplash proper has entered Hoary.

The installer has been activating the framebuffer by default for some time now, so we should use its approach as a starting point (see rootskel). There are machines where this is known to fail (some laptops especially), and we'll need to do something about those. In order for Ubuntu to be installed on such systems currently, the user must pass debian-installer/framebuffer=false, so we should have a way for that setting to propagate to the installed system (specifically, omitting the 'splash' parameter).

I'm happy for 'splash=' to stay on the default kernel command-line (it's not on the recovery line); usplash will do something pretty and equivalent and as best it can in text-mode.

[x86/amd64] The VESA video mode can only be set by passing 'video=' and/or 'vga='. This should also only be on the default kernel commandline [and not '(recovery)']. These just need to be dropped if 'debian-installer/framebuffer=false' was used at install time.

IIRC, the mode is set by the 16-bit pre-main code in the kernel; the FB can then be /accessed/ by loading 'vesafb'. I'm not sure what is hooking '/framebuffer=false' and where.

The even bigger challenge is appending those 'vga=' parameters in the first place.

ftp://netz.smurf.noris.de/{initrd.gz,vmlinuz} has my new keyboard selection code. Please test / try to break -- I'd like to get some confidence that this is actually working for >1 person before I upload the stuff to Hoary.

What the code does: Instead of displaying a list of languages, I ask the user to press a few specific keys. By evaluating the keycodes, I can determine which variety of $STRANGE_KEYBOARD you have.

(NB: I know the new parts don't have translations yet. That's next.)

• Console switching is broken. This will get fixed tomorrow.
• The mapping table may have bugs. In that case, either the normal selector pops up automatically, or you get a "Keycode 12 was not expected" message. If you run into this, please tell me which keys you pressed to get there, and their keycodes (you can get these with "showkey").

"The goal of the Ubuntu folks is to provide a more up-to-date Debian than Debian, while eliminating many of the potentially confusing installation options and permutations encountered when installing many Linux distributions. They accomplish these goals extremely well, with an easy-to-use installation process, a great system update and enhancement mechanism, and a distribution that makes a great starter--or permanent home--for Linux users who'd just like to use their computer to get work done."

"Commercial support for Ubuntu is available directly from Canonical, LTD (http://www.canonical.com/), which is the company that sponsors the Ubuntu project. Canonical's support offerings are listed on the Ubuntu site at http://www.ubuntulinux.org/support/paidsupport/. A substantial number of firms all over the world that provide support for Ubuntu are also listed in the Ubuntu Marketplace site at http://www.ubuntulinux.org/support/marketplace. The latter is an incredible testimonial to the wide-spread and well-established nature of Ubuntu after a relatively short time in Linux years."

If you see an article about Ubuntu in the community, trade or popular press, please let the Sounder know <sounder@lists.ubuntu.com>. Many of these will be put up on our "In The Press" webpage, which is receiving more love as of this year. ;-)

http://www.ubuntu.com/ubuntu/press/

For those of you that read the ubuntu-news list, you may have seen that due to a request, the Ubuntu Community Council discussed the status of the reply-to header at the meeting last week.

The issue at stake is more complex than many people, on both sides of the issue, have argued. Clearly, the lack of a reply-to-list function in at least one the major email clients that Ubuntu ships (Thunderbird) makes the lack of a reply-to a headache for many users. That said, setting a reply-to will break existing reply-to headers for some users of the list. For these and many other reasons, people feel very strongly both ways.

Additionally, the council expressed some hesitation at moving forward with any change specifically because the tone of recent discussion on the topic on this list has degenerated into disrespectful attacks and an unhelpful "us versus them" attitude. We're looking to a policy of enforcing the code of conduct more rigorously in the future.

With all that said, I'm happy to announce that the council has listened to arguments made by many who were respectful and constructive in their complaints and is going to switch the ubuntu-users mailing list (and only that list) to "reply-to-list" for a trial period. The topic will be discussed again at the next community council meeting.

Additionally, Canonical is looking into bountying reply-to-list functionality for Thunderbird in Ubuntu.

If you have strong feelings about the change, either way, please read up on the background of the decision and feel free to reply to this list or to email <ubuntu-users-owner@lists.ubuntu.com>.

On the lighter, but no less important side of the issue, you might want to be careful when you hit reply from now on. The messages will be public by default. ;)

Feature freeze is coming up very soon, and so this is a good time to take stock of what we've done, and how far we have to go.

First, if you're working on Hoary features, please go to http://www.ubuntu.com/wiki/HoaryGoals and update the status column for your project(s). There is a lot of work in progress, and we need to know where we stand overall. It's clear that we've achieved a great deal already, but many features are in need of status updates.

By feature freeze, goals which involve development work on packages in 'main' should meet the following criteria:

• Primary and Secondary goals should have initial code in Hoary, and ongoing development should be taking place in Hoary
• Targets of Opportunity should have essentially feature-complete code in Hoary, with only bug fixing and fine-tuning remaining

If you are working on one of these projects and are not uploading your development code to Hoary yet, then the project is at risk of falling behind schedule and being excluded from the release. Features which are not on this list will not be included in the release without a justifiable exception to the release process. New code needs to receive widespread testing as soon as possible so that it has time to stabilize for the final release.

So, if your work does not meet the conditions above, please follow up to this message with details of your situation (blocking items, outlook for the project, help needed, etc.) so that we can discuss how to proceed.

To whoever may care at Canonical, I seriously wonder if you are serious about having Ubuntu Documentation or not.

In the short time I have been with the project we have managed to achieve much on our own, but there are things on which we do need your support. All I can say is that getting that support has been slow to non-existent.

Understand that this is a very rapidly growing operation, with many projects involved and expanding as well. There are bound to be growing pains. The best that we can expect is that problems are addressed as they come up, and not before.

Again, I am available as a point of contact on Canonical-related issues. I can't promise to monitor every message on ubuntu-doc, but if you address me personally, I will generally respond.