[[!meta title="SIPB Bug-Squashing Hackathon for Lenny"]]

SIPB is running a **bug-squashing hackathon** for release-critical
bugs in Debian Lenny.

Place: **W20-557**, the SIPB office  
Date: **Saturday**, 2008-12-13, between end-of-classes and finals week  
Time: starting **2 PM**, running to about 10 PM; come for any portion

Contact the SIPB Chair, Greg Price (`price@mit.edu`), or Vice-Chair,
Nelson Elhage (`nelhage@mit.edu`), with any questions.  During the
hackathon just call the office at (617) 253-7788.


## FAQ

**Q**: What's Lenny?  
**A**: Lenny is the **upcoming next stable release** of Debian
GNU/Linux.  It was scheduled for September 2008 but has slipped to
spring 2009.  The last release was Etch in spring 2007, so Debian
users are eagerly awaiting a new release.

**Q**: What's a release-critical bug?  
**A**: A **release-critical (RC) bug** is a Debian bug of any of
the highest levels of severity.  RC bugs break a program completely,
break some users' systems, or do similarly bad things.  At last count
there were 109 bugs (below) affecting Lenny.  (**Update**: After the
hackathon it's 105, with more fixes in the pipeline.  Excellent.)
Every one of those bugs has to be dealt with one way or another before
Lenny will release.

**Q**: How is this list of bugs different from
[this one](http://bugs.debian.org/release-critical/other/testing.html)?  
**A**: The list on `bugs.debian.org` includes bugs which have been
fixed, but haven't passed a requisite waiting period before being
introduced into Lenny. Our list is only bugs for which there is no
fix.

**Q**: I use **Ubuntu**.  Why do I care about Debian releases?  
**A**: Because Lenny is in the final, "freeze", stage of the cycle,
many Debian contributors are holding off new versions of the software
they maintain in order to focus on stabilizing and bugfixing Lenny.
Since Ubuntu depends on Debian for >90% of its packaging work, that
means less new software for Ubuntu until Lenny releases.

**Q**: I have **no experience hacking on Debian**.  
**A**: No problem, we have three Debian Developers pledged to
attend, plus Debian-packaging experts from SIPB's Debathena and XVM
projects.  They'll all be focussed on helping newer people find a good
bug, make progress and stay unstuck on solving it, and get the fixes
applied in Debian.  Just come ready to help with the skills you have;
you'll be sure to learn something.

**Q**: I don't have a lot of programming experience.  
**A**: No problem, **not every bug requires programming** to fix.
Some bugs concern documentation or copyright issues, and anyone
willing to track stuff down and write in English precisely can help.
You'll still get experience with the issues software in the real world
has to deal with, and probably read some code along the way.

## Useful Resources

[Debian Policy Manual](http://www.debian.org/doc/debian-policy/): There
will be people at the hackathon to help you with the packaging and
policy aspects of updating Debian packages, but the Debian Policy
Manual is a good reference.

[Debian New Maintainers'
Guide](http://www.us.debian.org/doc/maint-guide/): Where the Policy Manual is a fairly declarative document, this
is more of a tutorial on how to build packages that comply with Debian
policy

[tabbott's Packaging Tutorial](http://debathena.mit.edu/packaging/): A
summary of building Debian packages with CDBS, Tim's tutorial also
includes a long list of useful commands for any sort of package
development, as well as a list of useful sites

[SIPB IAP class on Debian](http://stuff.mit.edu/iap/2009/#debian): A
workshop where you can learn more about Debian packaging (the easy
way!  some of the packages you may have dealt with go through
unnecessary complexity), with lots of hands-on examples.

## Useful Packages

The following Debian packages are useful for doing Debian development:
`build-essential cdbs debhelper wdiff devscripts dh-make dpatch
dpkg-awk dpkg-dev equivs fakeroot lintian quilt`

If you're an emacs user, you may also want: `debian-el devscripts-el
dpkg-dev-el`

## The Bugs

See [[lenny-bugs-all]] for a complete list.  Attack one of the bugs that
look good, or read through the unclassified ones to find the good
ones.