ScottK might have something to say ...

While I was at UDS I did a "Bad" thing to my netbook and had to re-install.

The Dell Mini 10v ships with BCM4312 wireless. As a result it needs restricted drivers for wifi to work. On the Kubuntu Netbook Remix ISO we included everything needed to get the Broadcom STA driver installed and working. Unfortunately, Jockey doesn't know where to find the driver when the install is from USB.

After install you need to make a few adjustments. Leave the USB device you installed from in after the first reboot.

First add the device to /etc/apt/sources.list. The line to be added will look somewhat like:

deb file:///media/disk/ lucid main restricted

where media/disk is the path to your device

Then fire up jockey (Hardware Drivers under system). It should show you two options for driver install. You want to install the STA driver.

Once jockey is finished, you should have wifi.

So that solves the "you must have internet to get internet" Catch-22.

It's fortunate I was at UDS when this happened, I was able to talk to several different people and lay out a plan to fix this for Maverick.

Posted by Scott Kitterman at 10:49 PM | Permalink | Comments (2)

If you are using clamav-daemon on releases before Lucid (version << 0.96) and on a 32bit architecture, there is a roughly 1 in 4 chance it crashed today. See the clamav-announce message for details:

http://lurker.clamav.net/message/20100507.110656.573e90d7.en.html

Posted by Scott Kitterman at 09:30 AM | Permalink | Comments (0)

Once the release finally happens today, Ubuntu will have some new siblings. One of them will be Kubuntu Netbook Edition.

Why Kubuntu Netbook Edition?

1. Kubuntu because it's built on Kubuntu and KDE.
2. Netbook because that's the target system.
3. Edition because it is all built from FOSS packages available in the official archives.

First there was a nugget of an idea from upstream. KDE should have a different approach for netbooks. About the same time we had the developer summit to plan the Karmic release. Fortunately we had good representation from both the Kubuntu community and KDE developers and we organized around the idea of an early look at the KDE netbook vision (it will be released "for real" with KDE 4.4 in January 2010).

We came up with a basic plan and got it approved.

Then as we got to work, interesting things started to happen. We created a new subset of the Kubuntu seeds to define the packages for a standard netbook install. We created a set of default settings designed for the smaller screens on netbooks. Then we started to make an ISO image for Kubuntu Netbook. One thing I noticed throughout this process was that every time we needed a little bit of help or direction from someone at Canonical (trust me, I did not navigate the internals of debian-cd to add another image type without help) they were there to help us keep moving along.

By the Alpha 3 milestone, Kubuntu Netbook existed. At this point, Kubuntu Netbook was nothing more than a miniature Kubuntu. Thanks to the inherent scalability of KDE4, this was pretty easy to do.

Fortunately for us, the KDE developers had done their before they started and already had a good idea where they wanted to http://morpheuz.cc/netbook.pdf and made rapid progress.

By Alpha 5 we had a svn snapshot of the new plasma netbook packaged and working. From that point on, we had a solid foundation for development and got to a pretty good result.

I'm very pleased with the way that Ubuntu developers (many, but not all of which work for Canonical) have jumped in and helped out when we needed it. This is a supportedt release just like Kubuntu or Ubuntu. It's a first effort, but I think a pretty good one that would not have been possible without all the help.

We've got three netbooks running Kubuntu Netbook Edition here at our house and we're all pretty happy. I hope everyone else enjoys it too.

Of course we can't get too satisfied with what we have. While we were off integrating and testing the early version of Plasma Netbook, upstream has been busy working on the final version we'll see in Lucid Lynx.

Posted by Scott Kitterman at 01:45 AM | Permalink | Comments (2)

A couple of weeks ago, I flew to Chicago with my wife and three kids for the wedding of one of my wife's cousins. As we were about to board the return flight, my middle daughter (15) noticed that her suitcase was missing. We didn't have time to do anything except a quick look around and then get on the plane to go home.

Once we were home, after a lot of calling around by my wife and the daughter in question, they located the bag. It was found at the TSA security checkpoint. This was better than we had hoped for.

TSA told us all we had to do was have the airline come pick it up and with our authorization, they would turn the bag over to United for them to send it back to us. All seemed well.

Unfortunately, United's position was that since it wasn't a checked bag, it wasn't their problem. United's motto used to be "Fly the friendly skies." I checked and I see that's no longer the case. At least they aren't still pretending.

As soon as I heard this, I said to my wife, "Wait, I know people in Chicago." I know Ubuntu developers who live there and I know there is an active Chicago loco team.

I visited #ubuntu-chicago (IRC on freenode) and almost immediately had multiple offers of help. Thanks to
Tony Narlock (skiquel), the suitcase is on it's way home and my daughter is out of having to do a lot of shopping for clothes with money she doesn't have. Thanks again Tony.

Being in the Ubuntu community is kind of like having family everywhere.

Posted by Scott Kitterman at 10:45 AM | Permalink | Comments (8)

Not much more to say. Have a look:

Posted by Scott Kitterman at 11:20 PM | Permalink | Comments (7)

Oh dear. Is any comment actually necessary:

I won't even go into the pain of trying to actually speak to someone to complain about it. At least the web tech support understood it was a dumb idea. Progress for our side, I guess.

Posted by Scott Kitterman at 01:40 AM | Permalink | Comments (1)

Unless you've been living under a rock for the last half year, you've almost certainly heard of Canonical's Ayatana Project. At UDS Karmic in Barcelona we spent quite some time working out the best was for Kubuntu, KDE, and Ayatana to work together. We came up with a plan.

This plan gives Ayatana room to innovate and explore new concepts, preserves Kubuntu's position as a very upstream KDE focused distribution, and makes it easy for Ayatana's good work to benefit upstream.

We didn't agree on everything, but we did agree on the idea that a user's notifications should be consistent. From a Kubuntu perspective this meant that if a user was using a non-KDE application in a KDE session, then notifications should look and feel KDE like.

I gather it took quite some discussion on the XDG list to get agreement on how to achieve this, but Aurélien Gâteau has now landed patches in KDE svn (for KDE 4.4) and in the Ubuntu archive for Karmic (KDE 4.3) to enable this [1] [2] [3] [4].

I think this is a great first step for Ayatana, Kubuntu, and KDE. I look forward to more.

[1] href="https://launchpad.net/ubuntu/karmic/+source/kde4libs/4:4.2.96-0ubuntu5
[2] https://launchpad.net/ubuntu/karmic/+source/kdebase/4:4.2.96-0ubuntu2
[3] https://launchpad.net/ubuntu/karmic/+source/kdebase-runtime/4:4.2.96-0ubuntu2
[4] https://launchpad.net/ubuntu/karmic/+source/kdebase-workspace/4:4.2.96-0ubuntu4

Posted by Scott Kitterman at 04:15 PM | Permalink | Comments (6)

One of our goals for Kubuntu in this development cycle is to introduce a new sub-flavor of Kubuntu for netbooks (thus Kubuntu Netbook Edition).

We took a significant step forward on Friday when we got our first images:

http://cdimage.ubuntu.com/kubuntu-netbook/daily-live/current/

They are not optimized for netbooks yet, but KDE is natively pretty flexible about scale so it works reasonably well.

Now we need testers. I'm particularly interested in testing with a variety of netbook hardware. If you have a system that needs proprietary, undistributable modules like poulsbo (e.g. Dell mini 10), then this won't work. I did already discover that the Broadcom drivers my mini 10v needs were not on the ISO and that's fixed.

We have two goals for this release:

1. We want to offer a traditional KDE computing experience scaled to the smaller form factor. We should have a first cut at this done soon and be ready for some real testing to see what was missed.

2. Offer a really exciting and new netbook experience using the plasma-netbook shell. The pieces we need for this are still under heavy development (it looks like Kubuntu will be the first distro to release with it) and so it will arrive somewhat late and may have to be deferred to Karmic +1.

For now, please install from our new image and see if all your hardware works. I'll let you know when we're ready for more.

For now you'll need to use the GTK usb-creator, but we are also close to having both KDE and Windows USB creator variants.

Posted by Scott Kitterman at 11:45 PM | Permalink | Comments (9)

When I was growing up, this was the advertising slogan of the "Yellow pages". This was (is) the business telephone directory put out by the local telephone company throughout the US (I have no idea how localized the term Yellow Pages is, so I explain, just in case).

Recently I had an immediate need for a horse riding helmet for one of our daughters. The need was immediate because she was leaving for camp the next day.

This is not the kind of thing I normally purchase and I've only lived in this area for a few years, so I had no idea where to go. Without giving it a lot of thought, I fired up Google Local and found a great specialty shop close to our house. I had no idea it was there because it was on the back side of a small shopping center that I didn't know had a back side.

While we were there, I had a nice chat with the owner and mentioned I'd found the store via Google and his web site. He mentioned that he gets a lot of new customers that way. He's recently decided to cancel all his "Yellow Pages" advertising. He said he views it as a waste of money. His web site is a lot less expensive and works much better. His comment about "Yellow Pages" was something like "No one uses it anymore".

This got me thinking. I have a current copy. The telephone company delivers it every year. I can't remember the last time I actually used it instead of going online.

This seems like another small industry that is just going to go away. I hadn't thought of this one before.

Posted by Scott Kitterman at 10:32 PM | Permalink | Comments (5)

This UDS was my most intense so far. We got some very good work done, but I need to decompress a little before I blog on that.

The choice of venue was personally interesting to me in a way that (like my last UDS in Prague) I had not anticipated. As many of you will know already, a long time ago (in what seems almost like a different life) I was in the US Navy. I spent Christmas 1991 and New Years Day 1992 in Barcelona.

For those of you to young to remember, January 1, 1992 was a day that marked a significant change in the world. It was the first day in roughly 75 years in which there was no Union of the Soviet Socialist Republics (USSR). We had heard the news that this was happening, but many of us wondered how much of this was real change and how much of this was cosmetic.

At the pier across from us there was a merchant ship of the former USSR. I still remember coming topside and being surprised to see there were already sailors up on the ship's stack with a cutting torch cutting the hammer and sickle of the USSR down off their ship. That was the moment when it really hit me that the world had changed in a way that really couldn't be reversed.

There is a connection to Ubuntu here too, beyond the physical location of UDS. Whatever your opinion of my country (I'll tell you in advance I don't intend to have a debate about it's goodness/badness and will not publish comments either way), I felt I was there making a sacrifice in the service of freedom. In that time and place it was the best way I knew how to do it. Today I do stuff like take an unpaid week off of work and go to UDS to help make Ubuntu better. This is also done in the service of freedom.

There are a lot of people all over the world who don't want others to be free. Keep in mind that what we do in Ubuntu is part of a larger struggle to make sure these people do not succeed when considering if it's worth it to do one more bug triage, patch fix, or whatever it is you do to make Ubuntu better.

Posted by Scott Kitterman at 08:13 AM | Permalink | Comments (4)

I guess the reaction to my last post is a good reminder that a distro developer ought to go see what upstream has already done before considering what the distro ought to add (I knew that). I also knew about the new systray protocol in KDE 4.3. I've even watched the video before. I completely brain dumped about it last night when I was writing.

Fundamentally it looks like I'll be able to get rid of all the systray stuff i don't care to see just using that. So that's pretty cool. I just wish I'd remembered before I put the time into writing that last night. Ugh.

Posted by Scott Kitterman at 12:07 AM | Permalink | Comments (1)

One of the stated goals of Canonical's Ayatana project is to reduce the amount of real estate used by the systray. This was one of the rationales for the Indicator Applet introduced in Ubuntu 9.04.

In preparation for UDS Karmic I decided to take a look at my Kubuntu 9.04 systray (as well as a few systray like items that in KDE 4.2 aren't or can't be in the actual systray). It looks like this:

I also experimented with removing some of these items to see how I experienced it.

Moving from left to right:

USB stick/SD card (Device notifier) - I don't see any need for this to be on the panel/systray by default at all. Make a appearance when you've got a device to notify about.

Sound (Kmix) - I rarely need this. I've got multimedia keys on my laptop (and they work - including the notifications about volume setting). This could easily be somewhere else, less readily available. It certainly doesn't need to be visible in the systray at all times for everyone.

Display (X Resize and Rotate) - I think I've only ever used this when setting up my laptop to work with a projector. I have a vague recollection of this only being started by default as a workaround for a bug, but don't quote me on that. I definitely don't need to see it.

Passwords (Kwallet) - I am sometimes vaguely interested in if the wallet is open or not, but I virtually never click on it. Generally if something needs access to the wallet the application asks for it. No need for this on the systray.

IRC (Quassel) - I click on this on all the time. Sometimes it's just to get to IRC to see what's up, sometimes I right click on the icon to connect to Quassel's core component), and when I want to get to a channel where I was highlighted, if I don't click on the notification action, I can click on the Quassel icon to get to the correct channel quickly and easily. I would not want this to be harder to get to.

RSS (aKrogator) - I click on this pretty regularly to read feeds when I'm taking a break from working on something. This is useful. It's not just for getting to read feeds, but also for triggering manual checks for updates. I could live with this being two clicks away, but like it in the systray.

Clipboard (Klipper) - I use this all the time. It's a great thing to have and the systray is a lovely place for it.

Email (Kmail) - I use this very regularly to get to Kmail. I have a lot of windows open and finding the one that's Kmail is hard. If I can click on the systray icon and get to it, it's very handy. I do not use notifications for mail, I don't even pay much attention to the number on the icon, I mostly just need a quick way to get to kmail. If the icon weren't reliably in the systray, that would a step back for me.

Network (Plasma Widget Network Management) - I really don't care about this much beyond am I connected. I could live without seeing this if I got notified on disconnect (currenlty I just get connection notifications).

Battery (Plasma Widget Battery Monitor) - I moved the battery from the panel onto the desktop where I don't see it unless I minimize everything (i.e. almost never unless I explicitly look). I found that the battery low/battery warning notifications were generally sufficient. Until after the battery warning notification I almost never looked. Afterwards I tended to peak at it fairly regularly. Based on this, I don't see a need for direct access, just an easy way to get to it once the battery was low. For bonus points it might appear in the systray after the battery hit warning level.

So once I got through looking at what systray and systray like items I was interested in, I was left with wanting something that contained an easy way to get to the things that had been removed and this:

Jordan Mantha's message on the Ayatana mailing list is what got me thinking about this. Having looked at my own needs, despite using a different desktop environment, they appear similar. "system-to-user" indications are a fruitful place to find opportunity to reduce the footprint of systray/notification area. I'd be interested to see Ayatana take this on.

Posted by Scott Kitterman at 01:23 AM | Permalink | Comments (11)

Clamav is one of those packages where is order just to stay even you have to keep moving ahead. If you don't keep up to date, then the bad guys have stuff that you can't detect.

Clamav 0.95 appeared late in the Jaunty development cycle, but with help from the other members of the Clamav Update Team and the Debian Clamav Packaging Project we got not only Clamav 0.95.1 into Jaunty, but all the reverse dependencies updated and tested.

There were a few glitches in the clamav-milter packaging and some additions to the apparmor profile that have been fixed in post-release updates. I think we have a solid clamav package in Jaunty now.

At the same time we were working to test and integrate clamav 0.95.x in Jaunty, we were also working to finish testing 0.94.2 for Dapper and Hardy. We also got that done, so the version that Intrepid released with is available for Dapper/Hardy/Intrepid (and has been patched to deal with all known post-release security issues).

Finally, we've prepared packages to test backporting clamav 0.95.1 to all supported releases. They are in the ubuntu-clamav PPA. Once we get these tested we'll get them into the official backports repository. If you test these packages, please mark your results on the team wiki.

If you're interested in helping out, do some testing and apply to join the team.

Posted by Scott Kitterman at 12:45 AM | Permalink | Comments (0)

The Quassel developers are keeping up their consistent record of responsiveness to feedback. A couple of weeks ago, when I wrote about notifications in Kubuntu 9.04, I mentioned that I'd like the ability to easily get to the IRC channel related to the most recent notification from Quassel. I got a patch almost immediately that I've been testing.

I'm very happy with it and report that I feel a lot more relaxed about responding to notifications from Quassel. If I want to respond to an notification after it's already disappeared, I just click on Quassel's systray icon and I get right there.

Anyone who wants to try it out can upgrade from my PPA. This update includes the patch for that and another dealing with correctly setting notification timeouts. Some users who use Quassel outside of a KDE environment have mentioned that notifications didn't go away and had to be manually dismissed. I'm interested to hear if this patch makes a difference.

This patches and a number of other bug fixes will be out shortly in Quassel 0.4.2. Once it's released and I get it pacakged for Karmic, I'll also get it into jaunty-backports for people who want to try it without upgrading their entire system.

Posted by Scott Kitterman at 02:30 AM | Permalink | Comments (0)

Back in early January, I wrote about what I was hoping for with notifications in Jaunty. I got the first part of my wish the very next day. The story has a happy ending, but it got a little twisty along the way.

Back in January, what I showed you was not a KDE notification. It was generated by Qt and provided by (I think) the standard libnotify (Canonical's notify-osd did not exist yet). It wasn't at all pretty in a KDE environment, but it worked. I got a notification and, if I wanted, I clicked on it and Quassel appeared. If I didn't, it went away. Things were functional, if not pretty.

I week later we activated the then experimental KDE integration for Quassel and things went initally downhill. I was still running Intrepid with KDE 4.1 and the KDE Plasma notifications in KDE 4.1 were ugly and they were persistent (plus the action to click on them stopped working). Having to manually dismiss all the notifications was a real annoyance. This is one aspect of notifications upon which I completely agree with Mark Shuttleworth.

Once I upgraded to KDE 4.2, things got good again. Not only did notifications start going away on their own, but the Quassel developers figured out the problem with integrating actions via KNotification. The result, I think is extremely usable and visually appealing:

The part that makes this notification just killer for me though is not just the action, but that when I click on View, not only does it take me to Quassel, it takes me to the channel that triggered the notification. I've used IRC with no notifications (just a flashing icon in the systray), with non-interactive notificaitons, with notifications that just took me to the right application, and now with notifications that take me to the right channel. This is far and away the best I've had so far.

To give credit where it is due, now that I have an application with a really useful notification action, I start to see, a little bit, Mark Shuttleworth's point about actions on notifications creating a "weighty obligation to act". The trick being that I have to get to it before it goes away to be useful. I don't at all agree that taking the action away is a good thing. While this could be better, I'm very glad to have it.

I've already followed up with the Quassel developers and they've added a solution to this problem to their feature plan for their next release. Their responsiveness to feedback that I blogged about in January continues. The solution is in their systray icon. Currently (like most applications) it just raises and lowers the application window when you click on it. For the next release, if Quassel is not on top, it will remember where your last notification came from and take you there. Once that's in place, the rush is gone.

KNotification is working effectively throughout KDE 4.2. The progress dialogue when you copy files is a notification. When you click on a link that opens a new window, it's a notification:

All in all, KDE made a huge step forward in notifications in KDE 4.2 and I'm very happy to see it. One of the interesting aspects of the design is that while transient notifications can exist for varying lengths of time (for example until the file copy is complete), they only stay maximized for a short period. If they still exist, but aren't maximized they get their own systray icon (A nice stylized i - for information, I guess):

I'm quite pleased with the progress made in KDE 4.2. I'm interested to see how the new systray protocol in KDE 4.3 evolves and is integrated with the notification system for the Karmic Koala.

Posted by Scott Kitterman at 02:11 AM | Permalink | Comments (7)

Since there has been a some recent notoriety around the notion that usability is somehow particularly difficult in FOSS projects, I thought it might be nice to share a recent success story.

For the Jaunty development cycle Kubuntu is working to transition all the applications shipped on the installation CD from KDE3 to KDE4 versions. One hard spot was an IRC client. Konversation, our long time default client still just has a KDE3 release and a KDE4 version is not expected in time for Jaunty. A number of Kubuntu developers had tried Quassel and suggested it be considered. We surveyed the landscape and concluded it was our most likely candidate for a KDE4 IRC client for Jaunty. Quassel is a very young project and one problem is that much of their user interface was oriented toward expert IRC users. We needed something more accessible for new users since IRC is one of our primary support mechanisms for new users.

Fortunately for Kubuntu, Celeste Lyn Paul (seele) of the KDE Usability Project is active with the Kubuntu team and volunteered to do a expert usability review to give the developers some ideas about what most needed doing to make it suitable as our default IRC client.

How this process looked as it was happening from the developer's perspective is captured in the blog of Manuel "Sputnick" Nickschas (Sput on IRC). Three months later, Quassel is the default IRC client for Kubuntu 9.04 (Jaunty Jackalope)l. One active member of the Kubuntu team, claydoh has done a great how-to for Quassel where you can see the results.

Today I pinged the main Quassel developers on IRC (of course) and asked them how they felt about the process and the usability review. Marcus "EgS" Eggenberger (edited slightly for flow) said:

When we started with quassel we never imagined to have a real userbase and ... one of those big things was seele's review for us. I was really speachless as seele told me how much time she put into this and it was really great since it was the first time we had some clear defined requirements to the UI which we never had before. Sput and I love to code but designing UI stuff is just not our thing.... also it made us focus on things we kept procrastinating.

Sput added:

I fully agree with Egs on that. [In addition to what I blogged] we also had several discussions with seele afterwards where she provided us with feedback and ideas. ... and in addition: I think it's a great idea to talk about the spirit and benefits of opensource!

So there you have it. FOSS usability at work making the things better for all of us.

Posted by Scott Kitterman at 08:24 PM | Permalink | Comments (9)

The Kubuntu team is proud to announce the release of Kubuntu 8.04.2, the second and final maintenance update to Kubuntu's 8.04 release. This release includes updated desktop, and alternate installation CDs for the i386 and amd64 architectures. This update is provided in recognition that the current Kubuntu release (8.10) with its cutting edge KDE 4 desktop is not yet appropriate for all users.

In all, over 200 updates have been integrated, and updated installation media has been provided so that fewer updates will need to be downloaded after installation. These include security updates, and corrections for other high-impact bugs, with a focus on maintaining stability and compatibility with Kubuntu 8.04.

The full release announcement can be found at kubuntu.org

P.S. Normally non-LTS releases do not get point releases. I'd like to thank Canonical and the Ubuntu Tech Board for making the resources available to do this non-standard update. I'd like to thank the Ubuntu Release team and all the volunteer testers for their help. I do hope this mid-life update of the installation CD for Kubuntu 8.04 makes things easier for the Kubuntu users who still prefer to use KDE3.

Posted by Scott Kitterman at 11:59 PM | Permalink | Comments (2)

If you follow the saga of the clamav anti-virus package in Ubuntu at all, you know it is painful. Anti-virus is one of those areas where you really do want the latest and greatest since the area is such a moving target. There are also quite a number of packages that integrate with clamav that have to be tested before we can bring a new version into the archive.

For coming up on two years now I've been working with a small group of people trying to get clamav updates tested and into not only the development release, but also into *-backports too. It's mostly grunt level testing with occasional forays into "Why the heck did that happen". It's not exciting, but it needs doing and for some reason I volunteered to lead the charge. I have struggled with how to find people who will help with this work.

One time, I even ventured into the forums to try and find volunteers. No luck. Or so I thought. A few weeks ago I got a ping on IRC from Gergely Imre (cemc on Freenode). He was interested in getting clamav updated on Hardy. He'd seen that post (a year and a half later) and tracked me down. So it turns out my trip to the forums was helpful, just not on the timescale I'd envisioned.

The intersection of the Hardy release for Ubuntu and Clamav 0.93 was particularly unfortunate. Clamav released 0.93 just very before Hardy's release and with all the changes there was no way we could test and patch the related packages before release. After release we started working on getting it tested for hardy-backports, but everyone involved is a volunteer, we all have other stuff to do, and it just never quite got done.

Then one day about this time last month, I get a PM from someone I'd never spoken to before. It turns out cemc had seen my forum post and had come to ask me about it. He wanted to get the current clamav into Hardy backports. This is where the being ready part comes in.

If you look at the Ubuntu Clamav wiki page you'll see that we had a lot of structure in place (thanks everyone, I did some of this, but only the smaller part). In addition to a matrix of what packages need testing, we had test procedures for most of them too. So we had a structure of clearly useful work that was ready and waiting for a new volunteer. This wasn't accidental. We had done this once before (updated Dapper/Feisty/Gutsy to the same version Hardy was released with) and the people doing the testing had made some good choices about documenting there work.

With one dedicated tester and (as a result) me committing time to keep him up to date in packages to test we had it done in pretty short order. So today you can find the current clamav releast in hardy-backports. You can also find updates to many packages that integrate with clamav. You can also be assured that we looked into the ones that weren't updated to make sure that the work with the new clamav.

Now he's also done the testing for Dapper and once the Jaunty Feature Freeze buildd crush passes I'll get the latest in dapper-backports too.

I've learned two lessons from this

1. Don't be too quick to conclude community outreach efforts have failed

2. When someone does show up and wants to help, it is really benificial to be ready.

Posted by Scott Kitterman at 11:48 PM | Permalink | Comments (0)

Normally Ubuntu does not do point updates of non-LTS releases, so in the normal course of preparation for the 8.04.2 milestone, Kubuntu ISO images were not updated.

Because of the KDE3 -> KDE4 transition, we recognize that 8.10 may not be appropriate for all Kubuntu users. We have worked very hard to keep Kubuntu Hardy a well maintained KDE3 release. After the regular Ubuntu 8.04.2 release I asked the Ubuntu Release team (and they got approval from the Ubuntu Tech Board) for a Kubuntu 8.04.2 point update due to it's special nature. This includes an update to the current (likely final) KDE3 release, KDE 3.5.10.

In order to get this release certified, we need testers. Most of the regular Kubuntu development/test community is running KDE4 now, so we need help from those of you still wanting KDE3.

The ISO tracker lists what needs testing. Please refer to the "Hardy .2" section. Because these images don't fit a standard set, the links to the ISO images on the tracker are wrong. The Live CD version is here and the alternate installer version is here. Both i386 and amd64 images are available and they all need testing.

Please remember that these are still test images, so handle with appropriate care. Report test results in the ISO tracker and file bugs and link them in the tracker as needed.

We will not be able to get this done without help from people who don't normally participate. If you feel continued KDE3 support in Kubuntu is important, now is your chance.

Posted by Scott Kitterman at 02:35 PM | Permalink | Comments (6)

DNSSEC is going to be a major PITA. So far it's sufficiently painful to have almost no deployment. I'm reasonably confident that either someone will have an incredibly great idea for an easy to deploy alternative or any of us who have anything to do with DNS are going to have to suck up the pain and learn to love it.

Most of you already probably heard about the Kaminsky DNS cache poisoning attack. I had my own little part in cleaning up the mess. What I suspect fewer people know is that the 'fix' was not a fix in the true sense of the word at all. What the fix did was push the statistics away from a successful attack. I've read reports of successful attacks on patched systems, but I really have no way of knowing how accurate they are.

Some people claim the attack was over-hyped, but I'm not one of them. I think DNS had a near death experience that it can never fully recover from. I have no idea what the next attack will be, but I'm pretty sure it's coming.

Doing my little bit to make the world a better place, I noticed that the latest major release of DKIM Milter included support for DNSSEC if the package was built with the Unbound DNS resolver. I've uploaded this change to Jaunty.

Additionally, I updated Unbound to the current release and configured it to be in a chroot (upstream default). So if you're interested in DKIM or other email authentication technologies, here's your shot to also play with DNSSEC and get a bit ahead of the power curve.

Posted by Scott Kitterman at 08:51 PM | Permalink | Comments (0)

This blog entry isn't meant to express an opinion about the current discussion surrounding the ctrl-alt-backspace changes for Jaunty. Since it's a Gnome only discussion, it doesn't actually affect me. I do think it's an important discussion that people ought to be more broadly aware of, not just for this particular instance, but for the design principals in play.

Because upstream decided to change to disable this by default and there was a rough (very rough, IMO, but I keep reminding myself that's not what I'm writing about ...) consensus at UDS to follow their lead, by default in Jaunty, ctrl-alt-backspace will no longer restart X. Because of the controversy, the spec includes in the implementation plan, "GUI tools will be implemented that permit re-enabling this. Tools must be available for both GNOME and KDE".

Alberto Milone went off and implemented that. It was merged into Kubuntu's packaging of KDE 4.2 last week. When Alberto asked to have the Gnome change merged today, a long discussion followed.

As part of that discussion, Mark Shuttleworth pointed people to Matthew Paul Thomas's blog posting, Why Free Software has poor usability, and how to improve it and said he was, "happy to keep discussing it, and would like to use MPT's commentary as the usability framework for that discussion.".

So I'd invite people to read through it and bring their perspective to this in a useful way (I hope this counts).

Posted by Scott Kitterman at 01:42 AM | Permalink | Comments (12)

This is likely going to be a bit controversial.

This bug is the result of what happens when good engineering practices are ignored.

In the xorg-server package in Intrepid, we have a patch called 107_fedora_dont_backfill_bg_none.patch. This is a hack that the author of the patch says is, "breaking protocol semantics that have been good for twenty years". Now for some time, this was a good hack. It helps a lot with making Compiz go faster. I'm not sure how long it's been around. The earliest I reference I found in the package's debian/changelog was:

xorg-server (2:1.2.0-3ubuntu1) feisty; urgency=low
...
* dropped patches (comments from Michel Daenzer):
- 107_fedora_dont_backfill_bg_none.patch
"Breaks X semantics and thus can't go in upstream. Apps/toolkits
need to be fixed not to use background none windows."
...
-- [redacted - it doesn't really matter who uploaded it] Mon, 26 Feb 2007 09:36:38 +0100

So it's been there at least two years. I don't know how much longer than that.

Later it got put back because it helped with performance. Up until KDE4 appears, it's all good. Unfortunately it appears no one ever told KDE or Qt about this and so they relied upon the established semantics of the protocol. Whenever a new object is drawn in KDE4, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay - perhaps 200ms - the garbage is properly replaced with the real object contents. This slows things down and is a major annoyance. I've had at least one user tell me they gave up Kubuntu because of it.

The good news is that the patch has been dropped (at least for now) in Jaunty, so there is hope for the future. I had a long discussion with some of the involved people on #ubuntu-devel yesterday about putting the same change in intrepid-updates, but lost out because dropping the patch now would be a performance regression for Compiz users in Ubuntu. For Intrepid KDE users we are going to provide alternate packages and see how it goes.

It is in the same PPA that we are using to provide experimental KDE 4.2 packages for Intrepid:

https://launchpad.net/~kubuntu-experimental/+archive/ppa

If you don't want all of KDE 4.2, it's also in my PPA:

https://launchpad.net/~kitterman/+archive/ppa

Please note that PPAs are now signed. Follow the instructions to add the repository keys.

These packages are not official K(U)buntu packages. Do not file bugs against them and it's not my fault if it does something bad to your computer (these are experimental). Let me know if you have problems though.

I've installed this on multiple Intel machines and got positive test reports from both Nvidia and ATI users.

So now we are stuck between a rock and a hard place between having xserver optimized for Compiz or Kwin.

I can understand why the hack was done and it looks like it's a good idea. The real problem is that getting the protocol and documentation changes to get this upstream was not done and it wasn't widely communicated through other means. I understand that changing the X protocol is not something to undertake lightly and a hard job to get done, but however long it takes, we'd be two years closer to being done if that work had been started at the same time the patch was written.

Hacks that solve problems are great, but you have to follow-up and do the hard engineering that gets them out of being a hack and into the way things are done.

There are more details in the actual bug.

Posted by Scott Kitterman at 04:31 PM | Permalink | Comments (12)

We had a small party at our house last Friday. Our youngest (age 5) got quite attached to one of the guests (age 8) and had to show her just everything. At one point I looked into the room that has the kid's computer (Kubuntu 8.10 with KDE 4.1.3) and saw that she had logged into her account and was giving her friend a tour. They were using Kolourpaint and making some very nice pictures together.

Due to this spontaneous act of Kubuntu evangelism, I had a chat with her dad and he left with one of my Kubuntu ShipIt CDs. Her dad uses Linux at work some, but had never considered it at home.

Posted by Scott Kitterman at 11:34 PM | Permalink | Comments (3)

For those of you running Jaunty, I've just updated the Quassel package to build with KDE4 integration. Also apachelogger added some goon postinst fun to create a certificate to use SSL between the client and the core if you are using the split architecture. Quassel comes with 4 package:

quassel - Use this if you don't know what you need. It's all in one like a traditional IRC client.

quassel-core - The sever component if you want to split quassel into a client/server system with the server elsewhere.

quassel-client - The client component for the split architecture.

quassel-data - This data package is needed for quassel and quassel-client.

Personally I use the split system (and most of the quassel developers do to). The current thinking is that it'll be the monolithic package (quassel) that we consider for the Kubuntu CD. The split architecture is just too much for new people.

So, please test. The quassel devs have been very responsive to issues. I had a build issue with the split architecture packages yesterday and it was fixed today. Please file bugs.

Posted by Scott Kitterman at 11:51 PM | Permalink | Comments (2)

Yesterday I wrote about (among other things) wanting to be able to click on a notification of from Quassel and end up in that application. Today I find on #quassel:

[08:09:46] Quassel IRC: sputnick master * rb324a124e384 /src/ (8 files in 2 dirs):
[08:09:46] Quassel IRC: Notification backends now can emit a signal activated() that tells MainWin to raise itself
[08:09:46] Quassel IRC: For now, this signal is emitted by systray, dbus and knotify. Unfortunately, raise() does not seem
[08:09:46] Quassel IRC: to work with kwin and (according to docs) neither on Windows. Furthermore, my knotify seems
[08:09:48] Quassel IRC: to be broken and doesn't signal a click at all. Thus, this whole thing got "limited" testing by me :)
[08:09:51] Quassel IRC: Take it as "might work under some circumstances in some environments". Feedback welcome.
[08:10:19] ScottK: try this and see if it raises the mainwin for you - I have failed on my box, but code-wise it *should* work... guess those are WM restrictions

It works. Thanks.

Of course this is just the first step, but it's great.

Posted by Scott Kitterman at 10:55 AM | Permalink | Comments (1)

It's kind of an interesting coincidence that about a week before Mark Shuttleworth posted in his blog about Canonical's plans for notifications, I had started experimenting with a new IRC client, Quassel, that provides a notification when you are highlighted or sent a personal message.

I've waited a bit to reply to his plans to gain more experience with notifications from Quassel and to think things through and not just give a knee jerk reaction. My initial reaction was very similar to Aaron Seigo's. So I've spent a week or two thinking about it on and off and I really haven't changed my mind.

Let me use Quassel's notification as an example and give you an idea of what I want and why...

The proposal from Mark Shuttleworth has two key points:

- There should be no actions on notifications.

- Notifications should not be displayed synchronously, but may be queued.

To the first point, my experience with Quassel notifications is that I will have one of two reactions:

1. I read the notification and I both understand the context sufficiently I don't need to look at the IRC channel and I have no immediate interest in responding. I get the notification, read it, and go back to what I was doing. This seems to fit the proposed model quite well. I want the information in the notification and I want it to hang around just long enough to read it and not require that I dismiss it.

This is how Quassel notifications work today. In some cases, it's great and it's a feature I really like that Konversation didn't have. In other cases, it drives me nuts.

2. I either need more context to understand the message or I want to reply. In this case I inevitably click on the notification thinking it will take me to the Quassel window with the message, even though I know it doesn't do that from repeated tries.

This is where I think the notifications proposal is off base. The idea of not requiring interaction (the notification just goes away after some period) is a good one. The idea of not allowing interaction is, I think flawed. I thought that perhaps I was misunderstanding the proposal and left a comment. It didn't draw a response, but a similar comment did get a reply. I understand the reply and it does make things not quite as bad as I had feared, but it still doesn't solve the problem.

For about a month now I've been using an application where I get regular notifications. I know that clicking on the notification doesn't actually do anything and I need to click on the icon in the taskbar. I know this and still I click on the notification first every single time. Why, because it's the thing that just flashed a message to me and it's the most natural thing in the world for me to click on that message to get more information/act on it.

I don't get stacks of notifications often enough to have a strong opinion about that bit, but Aaron Siego's idea to reduce notifications and not just queue them seems sensible to me. If there are a lot of notifications, queuing them will just make them late and less useful.

So what would I like to see in notifications:

1. Clicking on the notification takes me someplace to act on it.
2. I'm not required to dismiss it.
3. It'd be nice if it picked up the desktop theme and didn't give me Ubuntu standard colors on a Kubuntu desktop.

Fortunately, at least from my perspective, it doesn't look like the chances of this getting implemented in Kubuntu for Jaunty. It's not in any of the approved specs and I don't know of anyone who is working on it (Note: If someone is working on an implementation of this aimed at Kubuntu Jaunty, use Kubuntu developers would be interested to know about it).

It'd be nice to see a follow-up post explaining why having clicking on the notification doing something useful is a bad thing? The lack of it is currently driving me nuts.

Posted by Scott Kitterman at 09:16 PM | Permalink | Comments (14)

So I'm not at UDS this time and wondering how to listen in ...

Mike, the UDS wiki page still says, "If you cannot attend in person, you can still listen to the conferences or take part in them remotely. More information will be made available close to the conference date." Just how close are you guys planning?

Posted by Scott Kitterman at 11:45 AM | Permalink | Comments (0)

The description for ubuntu-devel-discuss says:

- Sharing of experiences with the current development branch of Ubuntu
- Technical questions about new features in the development branch
- Ideas and suggestions about future development of Ubuntu
- Point of contact for Ubuntu users to reach Ubuntu developers
- Open to all to subscribe, posting moderated for non-subscribers

This is a valuable resource for the community. It's one of the few places where users and developers routinely interact. This is at risk. I've recently heard a number of developers mention that they got tired of the noise and the rudeness on this list and unsubscribed. I did feel strongly enough about it to bring it up on the list in a thread called Do you really want developers to be on this list.

I'm bringing it up here too because I think it's important.

Ubuntu users (I include all the Ubuntu flavors in that): No developer is required to be on that list. It is up to you to make it one that we want to be on. This may be hard. You may have to sit on your hands instead of sending an emotionally satisfying, but really unpleasant response to a message about a problem you are having and are understandably upset about.

We have a Code of Conduct for a reason. Please be mindful of it.

Here are a few tips:

- Don't demean or impugn someone's knowledge or capability. We're all very busy and just because we don't drop everything and fix your personal problem right now doesn't make us idiots.
- Don't bother threatening to switch to another distribution. All that tells me is that I should ignore you. The only exception is those with support contracts and you should be dealing with your support contact and not whining on the list anyway.
- Don't claim we don't care. We do care, but we may have a different sense of priority than you do.
- Don't be angry. If you are, don't hit send. Wait until you calm down. Emotional messages tend to get emotional responses and people unsubscribing. They don't get problems fixed.
- Don't forget to pay attention. If you have a problem and we ask questions, please give us the courtesy of a prompt reply.

This isn't meant to say that Ubuntu developers are paragons of virtue, we aren't, but we've got plenty to do without reading ubuntu-devel-discuss and some of you really aren't helping us to want to invest the time in doing it. This isn't meant to minimize your problems or your frustrations. I understand they are real, but sometimes you really aren't helping yourself get your problem solved.

BTW, most of the advice above applies to comments in response to this posting (not that I expect mentioning that to help).

Posted by Scott Kitterman at 10:09 AM | Permalink | Comments (7)

I got asked about this on IRC today. Here's what I suggested:

I think in Intrepid we got to a 'complete' set of packages by adding clamav and spamassassin and took some first steps in Intregration.

The goal for Jaunty would be to be able to script installation of postfix, amavisd-new, spamasassin, and clamav in an integrated, working configuration with no hand editing of config files needed.

I can see three standard use cases that I suspect are common enough to support:

1. All in one mail server. Serves for sending and receiving mail and stores the user mail boxes. Includes virus and spam filtering.

2. MX Gateway server. Receives mail from the outside world, does spam and virus checks, and then relays to an internal server for final delivery.

3. Mailbox Serer. Internal box that holds user mailboxes. Supports IMAP and POP3.

With the work we did in Intrepid, we've got all the hooks to automate postfix setup and integration with amavisd-new and integration of amavisd-new with spamassassin and clamav. I'm not sure about what needs to be provided for integration with dovecot.

Posted by Scott Kitterman at 11:17 PM | Permalink | Comments (3)

Response in #kubuntu-devel today from a long time Gnome user I suggested give KDE4 a try:

ScottK: wow I'm pleasantly surprised, KDE4 is shockingly usable
and I like the ability to toggle compositing with a hotkey
thanks for encouraging me to try it :)

I have nothing to add.

Posted by Scott Kitterman at 02:01 PM | Permalink | Comments (6)

On Monday before Intrepid's release I decided to upgrade the kid's computer to Intrepid and KDE4 (did I mention, I'm now a fan). I had a little time. I'd upgraded one of my machines with no serious issues. How bad can it be I thought...

Two days later it was working. I managed to trip over serious hardware specific problems in both the kernel and X windows. Fortunately not horrible enough to stop the release (you're welcome to those, thank you very much) but definitely breaking my system. If these had happened a couple of years ago, I'd have been doomed (I know a little more now).

It turns out these bugs were pretty cool experiences. I got mentioned (not by name) in the official release notes. Bryce (the Ubuntu X maintainer) made a new wiki page for troubleshooting my X problem based on my input. I can see in the related bugs: Bug 290153 and Bug 290156 that other people have had similar problems to mine and benefited from the work-arounds I came up with.

So, it was a painful start, but the testing paid off even though the bugs aren't actually fixed yet. It may seem like last minute testing isn't going to help much, but it can make life easier for others. This is true post-release too, so if you are having problems, stick to working out a solution and document what you've done so others can benefit too.

The flip side is this can get a good dialogue going that can help you too. In Bug 290153 I got a comment today about a BIOS setting change that might help. I've got to look into that.

Posted by Scott Kitterman at 12:16 AM | Permalink | Comments (1)

Based on some of the feedback on my previous postings, there seems to be some interest in this topic. I'm sure that this is more like Perl than Python (there is more than one way to do it), but this is how I managed it....

Step 0: Decide you're going to switch them. There will be push back because it's not what all their friends have. Make your decision and stick with it. If you aren't going to stick with it, stop here.

Step 1: Get them using FOSS on Windows. In my case it was Firefox, Thunderbird, and Open Office. They still use these apps on Linux today. You need to find out what they are doing on the computer (you should know this anyway, but I digress ...) and figure out how you are going to support it on Linux.

Step 2: Gap analysis - There may be some things that just aren't happening. In our case my nemesis was iTunes and the particular iPod that Child #2 owned. At the time, it just wasn't happening. If they need to dual boot, let them dual boot and don't get very excited about it.

Step 3: Migrate their data and tell them the have to use Linux. In our house the response was very ho hum. You'll either get resistance (see step 0) or acceptance. Here we got mostly acceptance because the applications they use every day mostly didn't change and I helped them figure out how to use the applications that did change (AIM to Kopete took a little training).

Step 4: Relax. One thing I've told the kids is that because they are using Linux, I'm less worried about looking at exactly where they are surfing or what they are downloading because the operating system they are using is more secure. Teenagers see this as a feature.

Today the kids still dual boot for iTunes (now that we have Wine 1.0, that's doable, i just haven't gotten to it yet).

System configuration notes:

By default, Ubuntu inherits from Debian world readable Home directories. You'll want to change this if you have multiple children so they have some privacy from each other.

Change Open Office to use the MS Office file formats. This may be FOSS heresy, but the first time you don't get a call from your kid at school with a file on their memory stick in ODF and they can't turn in their homework, you'll be happy you made this change.

Policy considerations:

We treat the kids computer much like I would an employees. We've made it clear to them that it's our computer that we let them use and they should have no expectation of privacy. That doesn't mean that I sift through their Home directories on a daily basis, but I definitely reserve the right to go look and they know that.

The house rule is that they must have parental permission to boot into Windows. This is partly for security reasons (don't run Windows if you don't have to) and partly to make sure they don't kill off their sibling's homework project in an open session when they reboot.

P.S. They all seem to like KDE4 in Intrepid. If you haven't tried KDE4, you really ought to give it a shot even if you're a true Gnome fan. I suspect you may be pleasantly surprised.

Update: I guess someone liked this enough to translate it into Polish (they did ask and I said it was OK).

Posted by Scott Kitterman at 12:01 PM | Permalink | Comments (21)

After the final freeze on Sunday I started looking at pre-release testing. I decided it was time for the kids to experience KDE4. This mostly affects the teenagers (we have two). Our five year old is happy if I open Kate for her and she can practice typing (she also loves Mr. Potato Head).

They've been using Linux as their primary operating system for about 3 years now. They like it OK, but get frustrated with the ocassional incompatibilites with the things their friends (all on Windows) do. The younger of the two has borrowed my Kubuntu laptop and taken it to school to give presentations using OOO.

The upgrade itself is an interesting story having to do with some hardware specific regressions that will end up in the Intrepid release notes (yeah for testing).

The cool part was last night when one of them (who is not very technically minded at all) turned to me and said, "Dad, guess what? I figured out widgets. They are SO cool!". It's the first time I recall her excited about something she could do on the computer. Dad thinks that is "SO cool".

KDE4 - Making computers fun again.

Posted by Scott Kitterman at 09:10 AM | Permalink | Comments (4)

Unless some crisis in Universe/Multiverse erupts that is more unlikely than my imagination can, um, imagine, Universe/Multiverse is done for Intrepid. As of this writing, the MOTU Release Team bug list is empty (please don't add more, there's nothing we can do except point the bug at MOTU SRU and you can do that yourself). Thank you to everyone who worked hard on making Universe wonderful for Intrepid.

Each release seems to go a bit better. For Hardy we had some late library transitions that kept us busy up until final freeze (and even post release). This time we got it all done well in advance. We've come a long way since Feisty were MOTU were uploading all the way to final freeze with no coordination and we had some packages that were built on i386 and not on amd64.

It looks like we did a really good job of picking up RC bug fixes from Debian. Much better than I've seen in any previous release. Thanks to ajmitch for providing the RC bug tracker, to wgrant for significantly improving it's usability, and for everyone who worked on getting these fixes into Ubuntu (even if you only did it to bump your rank in Ubuntu Top Uploaders (you know who you are).

Thanks again everyone. Time to get busy looking at intrepid-updates until Jaunty opens.

Posted by Scott Kitterman at 10:31 AM | Permalink | Comments (2)

As I mentioned yesterday, the Intrepid postfix package has a couple of new scripts to make it easier to integrate SMTP filters and policy servers. They are easy to use, but not very flexible. My goal was to provide something that would pretty well just work for common use cases and at least give you a basis for other uses. Patches welcome.

The bad news is that due to a packaging bug, the man pages for the scripts are not in the Intrepid package. Each filter will give a help output if run with no arguments, however.

postfix-filter-add is meant to assist in integrating content filters such as amavisd-new with Postfix. It is specifically tuned for amavisd-new, so if using it for something else, be sure to check your /etc/postfix/master.cf afterwards and make sure it gave you a suitable result. After installing amavisd-new, you just run the script and then reload postfix. For example, if you want to call your smtpd service for amavisd-new 'amavislistener' and you want Postfix to listen at 127.0.0.1:10025 for return traffic from amavisd-new, you run:

sudo postfix-add-filter amavislistener 10025

All the needed master.cf entries will be added.

For policy server integration you have to provide the name of the policy server service you want to use, what user the policy server should run under, and the argument to use to spawn the policy server. Using my postfix-policyd-spf-python as an example package, it would look something like:

sudo postfix-policy-add policyd-spf policyd-spf /usr/bin/policyd-spf

Once again, the needed master.cf entries are added.

The changes needed for main.cf can either be done manually via your favorite editor or via postconf. For the SMTP filter example above, that could be:

sudo postconf -e "content_filter=amavislistener:[127.0.0.1]:10026"

Policy server main.cf entries need to be integrated into your smtpd_*_restrictions. In the case of an SPF policy server as above, doing it in smtpd_recipient_restrictions so it's done after recipient validation is recommend. You would add a check_policy_service unix:private/policyd-spf in the appropriate place, for example:

smtpd_recipient_restrictions =
reject_authenticated_sender_login_mismatch
check_policy_service unix:private/policyd-spf
permit_sasl_authenticated
permit_mynetworks
...
reject

It's not all just clickety-click just yet, but I hope this makes it easier. One capability these scripts do provide is the ability to fully script (in conjunction with postconf) filter and poilcy-server integration. I can imagine that might be of some assistance in large scale deployments (I could envision using these in a FAI installation script).

Posted by Scott Kitterman at 03:52 PM | Permalink | Comments (0)

One of the premises of Ubuntu is to pick one particular tool to do a particular job and focus on making that tool do the job well. For mail servers we've been gradually fleshing out a complete, solid stack to do the job. The long standing lineup is:

MTA (Mail Transfer Agent - the mail server): Postfix
MDA (Mail Delivery Agent - puts mail in the mailbox) Dovecot

In Hardy we added amavisd-new to Main to be a 'hub' for spam and virus filtering.

Now in Intrepid, clamav and spamassassin have been promoted to Main and so will have official security support. Ubuntu community developers (mostly me) have been supporting those packages well since Feisty was released, so the technical impact of official support isn't likely to be great, but I imagine Canonical security support will bring piece of mind to some.

I think we have a pretty complete selection here. Dovecot is also recommended for SASL authentication.

What we lack is an easy way to get all these pieces easily integrated. I made some progress with adding some scripts to the postfix package to make it easier to integrate SMTP filters like amavisd-new and policy servers with your postfix setup (I'll probably do a separate posting on those later). I had planned to use them to deliver an easy fully integrated Postfix, Amavisd-new, Clamav, Spamassassin experience. Unfortunately the Postfix pieces didn't land until just before Feature Freeze, so that's as far as we got for Intrepid. I'll pick that up for Jaunty and we'll see how far I can get it for 9.04.

In yesterday's post on clamav, I should have probably mentioned that the Ubuntu clamav package grew an apparmor profile (thanks jdstrand) for Intrepid, so there's that security bonus too.

Posted by Scott Kitterman at 12:24 PM | Permalink | Comments (3)

Clamav in Intrepid is currently the 0.94.1 release candidate and unless something upstream changes, that's what we will release Intrepid with. 0.94.1 final is scheduled for November 3.

So if you are running Intrepid and are interested in Clamav, this would be a good time to notice any problems you are having. File bugs in Launchpad and I'll push them upstream. The goal is to get fixes into 0.94.1 and then I convince the Ubuntu SRU team to let 0.94.1 into intrepid-updates.

Once we get to a final version in Intrepid, then I'll start looking at backporting to Hardy. I don't expect to backport to Dapper/Gutsy any more, but will still try to work on security patches for those releases. If anyone else is interested in backporting to Dapper/Gutsy, I'll be glad to give advice.

We are now using a common Git repository for Clamav packaging with Debian. See the pkg-clamav project on Alioth for details. This should help with keeping Debian and Ubuntu closely aligned. So far just Intrepid is there. but as we touch the other releases, I'll add them.

Posted by Scott Kitterman at 11:46 AM | Permalink | Comments (0)

I was lucky enough to get to attend the last Ubuntu Developer Summit (UDS) in Prague and work on planning this release. At the time I argued that KDE4 was unlikely to be mature enough to really be useful for most users until at least 9.04 and we ought to deliver parallel KDE3/KDE4 desktops for Intrepid. Riddell convinced me that we just didn't have the resources for it and so the only thing we could do is push as hard and fast as possible for the best KDE4 desktop we could assemble in the time we had.

Now that the Release Candidate is upon us and I've been using it in my daily work for some time now, I'm prepared to say that Riddell had the right plan. Kubuntu Intrepid has come together very well and is, in my experience totally usable for almost everything. It has a few rough spots and there are some small things from KDE3 that I still miss, but this is really ready for almost everyone to use.

This didn't happen by accident. It took a lot of hard work (to which I contributed in a small way*, but that's it). The community of Kubuntu developers really matured in this release and rose to the challenge. Looking on #kubuntu-devel I see a lot of people who have contributions they can justifiably be proud of what Kubuntu is about to deliver. It couldn't have been done without our Dear Leader, Jonathan Riddell, but equally he couldn't have done it without the amazing community developer group.

That said, if you need something totally stable, you might want to stay with Hardy. It is slightly crashier than KDE 3.5 in Hardy, but only slightly. I don't know of any major functions we don't support. The team did a very good job of sorting out where it was prudent to stay with KDE3 versions and where they could push on to KDE4.

My motto for Kubuntu 8.10 was going to be "The Intrepid Ibex searches for the tiger through the jungle of KDE4. Some days you eat the tiger. Other days the tiger eats you. Which will it be? Upgrade and find out!" Looking at it now, I think that's too harsh, but it will pay to do some work with a Live CD before you upgrade just to make sure what you need is there and working.

* I think my major Kubuntu contributions have been: bitching about missing stuff until someone fixed it, mangling the KDE3 kdegraphics package to produce a working kdvi after a user made a good case for why it was still needed, my now usual banging on Guidance so it doesn't crash so much, and staying up all night re-uploading all of KDE 4.1.1 because someone had made a small mistake with the kde4libs tarball.

Posted by Scott Kitterman at 08:51 AM | Permalink | Comments (13)

There have been enough times where I've wished I had a blog that I finally decided to get one. I'm not sure how much I'll write, but here I am.

Obligatory introduction:

I've run Ubuntu both on servers and a Kubuntu desktop since Dapper (in fact I'm typing this in Konqueror on that same Dapper desktop). I got involved in MOTU and Ubuntu development during Feisty. I became a MOTU (I think) early in the Gutsy development cycle. I got core-dev earlier this year.

Currently I'm one of the motu-release team that helps make sure we have Universe in some sense of order for release. I'm involved in both Kubuntu and Ubuntu Server development. I do reasonably well with packaging. I don't code except in Python. I'm also involved in Debian in a number of teams and will someday complete the NM process and (hopefully) be a DD too.

I believe in working closely with Debian and trying to minimize our differences to those that are needed due to policy or different empahsis. There are an order of magnitude more Debian developers than Ubuntu developers. Without a strong Debian, Ubuntu is in deep trouble.

I'm usually on IRC on one Ubuntu channel or another as ScottK. Feel free to say hi. Rumors to the contrary, I don't generally bite.

Posted by Scott Kitterman at 08:23 PM | Permalink | Comments (2)