You are here: / home

Tue, 07 Oct 2008

About the number of rc bugs

In addition to my last post, here some information about the current number of release critical bugs.

Yes, it is true, that our official bug tracker lists the next release has still 264 bugs¹. And some wonder, when Lenny will be released.

It's a little bit difficult to work with that page, let's look at the unofficial rc bug thingy I already mentioned in my previous post. As you might have noticed it supports several filters mechanism the official bts don't have. At the very bottom of the detailed list you'll see the overall number of the bugs matching your selected filter. So let's have a look at the number of bugs, which are already fixed in the unstable branch and need to propagate to Lenny. Currently that are 118 RC bugs.

Of those 264 preventing us to release, 118 are already fixed; the fix just hasn't arrived in Lenny, yet.

Okay, but there are still 147 rc Bugs open in both Lenny and Sid. So let's take a look at them. By using the filters at the top, you can calculate, that 19 already have a patch. 14 are marked pending (so they are already fixed, but the maintainer hasn't uploaded the package yet). 15 of these bugs have been reported multiple times and have been merged. Oh, and 3 are about packages in non-free and contrib.

Granted, for some of them, there is a patch, but the patch needs to be tested, or the bug has been marked pending by mistake. But still: If you ignore all these types of bugs, there are only 104 bugs left. one-hundred-and-four!

Summary: So the only thing left (beside the points I mention in my previous post) to do, is to migrate 118 fixes to Lenny somehow, get the 33 fixes for the probably fixed bugs uploaded, and fix the remaining 104 bugs.

Yes, that's still a lot of work to do... So let's get things rolling, shall we?

1: You might further notice, that the current stable release is affected by more than 700 bugs. However many of them are false counts, e.g. when a specific package doesn't build with a newer version of a compiler. The package in the current stable release is of course affected, so there it is kind of buggy. However, we can ignore these kind of bugs, since the newer version of the compiler isn't shipped in the current stable release at all. Those bugs should actually be tagged sid and lenny...

postet at 21:34 into [] permanent link

What you can do for Lenny (Update #2)

You probably noticed by now, that Debian GNU/Linux 5.0 aka Lenny hasn't been released in September. Well, that's a shame, but very easy to explain: Too many release critical bugs.

Well, it's pretty hard to estimate, how fast RC bugs will be fixed, and apparently our release team was a bit too optimistic :(

The big question is: What can you do, to help release Lenny at least in this quarter? That's pretty easy: Fix rc-bugs, take care, that the fixed packages are migrated to Lenny, do upgrade tests, document problems in the release-notes. Pretty simple, isn't it?

For users

Even as a simple user (aren't we all just users?) you may help getting Lenny released. Some things you can do:

• If you are running stable (aka Etch), you could consider upgrading to Lenny and see, if everything works fine. Currently there are no detailed release notes documenting the procedure, so you best way to test upgrades are to:
  1. Make backups
  2. Change your /etc/apt/sources.list
  3. Run aptitude update to get information about new packages
  4. Run aptitude install dpkg aptitude apt script to install the newest package management
  5. Run script aptitude full-upgrade
  6. Exit the environment of the script command, by typing exit
  If something goes wrong / something unexpected happens, please report it. If you already know a specific package, report a bug against that package. If you don't know, please report a bug describing the problem you experienced to the upgrade-reports package. If your problem is something, which can't be fixed properly, but should be documented (e.g. hardware support regressions, packages no longer available) please report a bug against the release-notes package (Bonus points if you not only report the bug, but also supply a paragraph to be added to the release notes).
  The command script will log the entire output of the command in the file typescript. Should something go wrong during the upgrade, please send this file along with your bug report.
  Update: If you upgraded succesfully, you should report that, too. There's a template for upgrade reports, which you can use.
• Speaking of the release notes: You can take a look at the bugs reported against the release notes and see if you can help there, e.g. by writing a paragraph describing a problem.
• Install the package devscripts (you'll need the version provided by backports.org, and run the script rc-alert --include-dists TU --include-dist-op and. You'll get a list of release critical bugs open for one of the packages you have installed. Guessing that you have them installed, because you are using them and are interested in them, you should have a very high interest to get these bugs fixed :)
  You can try to help, by trying to reproduce them and reporting that to the bug report. There are even some easy bugs, where the maintainer hasn't found the time to fix it, yet. Bug 497290 for example didn't need deep technical skills. It just needed someone with some time to collect the needed data for the copyright file.
• If you speak a language other than English, you might consider joining the translation efforts. While it is to late to translate the debian-installer or the installation guide to a new language for Lenny (perhaps for the next release then?), you could start translating the release notes to a not yet supported language. If you are willing to do so (which can be quite time consuming, especially in the final phase), please contact either your localization team or the debian doc mailing list if there's no local mailing list.

See? Even as a simple user without deeper technical knowledge you can help us getting Lenny in shape to be released. If you have technical knowledge: Very good! You might want to read the next section, too, and see what applies to you, there :)

For maintainers

It basically boils down to two things: If your packages have RC bugs open in Lenny fix them and take care, that the fix will propagate to Lenny. If your packages don't have RC bugs open, fix someone else's RC bug. Surely you don't think, the release team will fix the remaining rc bugs, do you? And surely you understand, that your shiny rc bug free packages are kind of useless, if they aren't released?

To search for bugs to be fixed, take a look at the unofficial rc bugs thingy. The URL lists RC bugs open in both Sid and Lenny. Obviously they should be fixed ASAP. If no one takes care about these packages, they might be removed from Lenny (if possible).

Again: Try to reproduce the bug, try fix it, upload an NMU (or send your patch to the bug report and search for an sponsor). You'll notice, that some of these bugs already have a patch. In that case, your job would be to test the patch, report that to the bug report and offer to sponsor an NMU.

Another interesting list is the list of rc bugs open only in Lenny. These bugs have been fixed, but the fix hasn't propagated to Lenny, yet. Normally, the release team will grant freeze exceptions for these packages if possible. However, if the changes to the fixed version are quite grave or the package in Sid depends on a newer package than in Lenny that's not possible. In these cases look out for packages marked as need tpu upload or similar.

Oh, and if you could refrain from upload new upstream versions of packages to Sid, you would make all our lives easier. Some reasons:

• New packages won't reach Lenny anyway.
• Upload new packages to Sid makes it harder to get a fix into Lenny should a new bug be found.
• Uploading a new package makes it harder for other packages depending on your package to be migrated to Lenny.
• You are wasting the buildd's time.

And of course you should spend your time fixing rc bugs anyway ;)

Update: Rhonda pointed out, that running rc-alert -d TU -o and will limit the output to bugs open in both Sid and Lenny, which is the more interesting list of bugs.

postet at 17:12 into [] permanent link

Wed, 01 Oct 2008

I'm done

I'm well aware of the irony of becoming a bachelor after getting married.

postet at 11:07 into [/other] permanent link

Tue, 23 Sep 2008

Slightly dramatized...

You know, that you did the right thing, when you leave the company building on your last working day, and the first thing comming to your mind is: Free at last!

postet at 20:04 into [/other] permanent link

Thu, 04 Sep 2008

Debian not complying to licenses

Daniel Baumann writes, that Debian wouldn't comply to some licenses due to embeded copies of syslinux binaries in its debian-cd package. To be exact he wrote: [..] if debian-cd is embedding a syslinux binary with a different version, it must contain the sources for it [..] (accentuation by me).

And -- since both debian-cd and syslinux are licensed under the terms of the GNU General Public Licences 2 (as statet in its copyright file) -- he is wrong. To comply to the license it is completely okay to Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, [..]. (Section 3b).

To the best of my knowledge we do archive all sources of all uploads (even if not public accessible, ask an ftp-master for details about source-morgue). So we do comply to the license.

Update: source-morgue doesn't guarantee all sources to be present. But all the syslinux sources mentioned by Daniel are present.

PS: Of course that doesn't mean embeding a binary is okay policy wise...

PS2: In future it's planed to have snapshot.debian.org for that; don't know about the state of that, yet.

postet at 21:07 into [] permanent link

Fri, 29 Aug 2008

How to code... not!

The other day I had the "pleasure" to debug some PHP code. It always showed the very useful error message Database Error.

As it turned out, this error message is printed out at over 38 (!) different places of the PHP script I had to debug. It also included several other PHP scripts, which printed the very same error message.

Please, if you are to lazy to print useful error messages, at least make them unique, so the poor soul who got the task to debug your stuff knows more or less where the error happens. Even numbering all your Database Errors would have helped a bit...

postet at 16:39 into [] permanent link

Tue, 19 Aug 2008

Why free is better than open

You might have noticed, that the latest issue of the Debian Project News was delayed. It where ready - more or less in time (thanks for those helping us), but for some reason it didn't passed the spam filters of our listserver.

Today listmaster explained we why. The reason: I mentioned and linked to a Debian birthday party, which was celebrated virtually in second live. It took place on their free and open Island which has the URL www.freeandopenisland.org.

Noticed anything? I'll write it down again: www.freeandopenisland.org.

That's why free is better than open ;)

PS: The pictures of that party look kind of cool. A virtual party in a virtual world where virtual people wear virtual Debian T-Shirts...

postet at 22:28 into [] permanent link

Mon, 18 Aug 2008

How to make my live easier...

... (at least concerning the Debian Project News):

Often when reading planet I notice something which might be interesting for the next issue of the Debian Project News. Often I don't write something up right now, but just add a link to that on the todo list.

So when finally writing the DPN, I often end up with the link to a blog not mentioning to whom it belongs. It's quite difficult to write an article about someone bringing up a topic, without mentioning who it was ;)

So pretty please: If you want to make our life easier, make sure that the HTML version of your blog mentions somewhere who you are. Linking to a contact page is nice, but is still more work for us. Linking to your ASCII armored GPG-key is... well... even more work.

Thanks!

postet at 19:58 into [] permanent link

Mon, 11 Aug 2008

Thanks to the DebConf video team

I'm not attending DebConf. I don't have much time these days :(

But if I can, I enjoy watching the video streams and participating via IRC.

So many thanks to the DebConf video team!

By the way: Something that seems to haven't found it's way to planet, yet: You can send kudos to the video team at http://wiki.debconf.org/wiki/DebConf8/Videoteam/Thanks! Please add something nice to keep them motivated; they are doing a HUGE job!

postet at 22:05 into [/events] permanent link