I have been organizing and attending many Free Software events in various campuses across the country, what sets DebUtsav@Amrita apart from all of them is the passion and enthusiasm shown by the students. It is pleasure talking to students who are already contributing to Free Software. It is a delightful break from having to explain what Free Software is about and why students should contribute to Free Software. We could just share our expereinces and listen to what they have been doing. We could discuss the challenges and how to tackle them. It is a model we want to emulate in other campuses. I could feel the inspiration in the participants when they saw the girls at the registration desk talking about contributing to the linux kernel, git for humans and zsh. So many women participating in Free Software is a rare scene for any community.
We have been organizing MinDebConfs and DebUtsav(am)s for many years with the idea of introducing debian to students and guiding them to start contributing. This time we had some passionate debates over name and content of the event. Some members of the community insisted we focus on debian only if we call it a mini debconf, because all mini debconfs have been organized like that. But Amrita was different because they already had a big and passionate community of Free Software contributors and not giving them an opportunity to share their work was not an option for us. So we renamed the event to DebUtsav, since it is a new brand we are creating, we are not constrained by the content of the previous editions. DebUtsav is the meeting point of Debian and the wider Free Software community. It is a place to exchange experiences and collaborate.
We wanted to bring some debian contributers outside India but it did not work out. Hopefully in future events we will be able to do that. Harish (I have been interacting with him most of the time) and the entire FOSS team at Amrita gets the credit of organizing this event so nicely aganst all odds. Due to the unexpected closing down of the college there was a big drop in participants than we anticipated. The FOSS team refused to leave the college and made sure the event is organized as expected. Since we had a small crowd we could do it informally and give attention to everyone.
I was taking ruby packaging sessions and hope to get a few more contributors to the ruby packaging team. I’m hoping to see more campuses becoming active in Free Software like Amrita and we’d like to organize more debutsavs and minidebconfs. We are hoping to bring main DebConf to India if we are successful in creating a strong community across India in the next two years. Contact me if you’d like to organize on event at your college or you want to help out in organizing more events.
We ran a hacknight to setup diaspora and hoping to see them join us in running more diaspora pods to strengthen the network. We also certified some laptops for h-node.org 100% Free Software compatible hardware database.
Read Balu’s blog at http://balasankarc.in/tech/celebrating-deepavali-differently-debutsav-14/
Photos of the event https://poddery.com/posts/1407655
I was thinking about another Kerala trip as my friend and NIT Calicut classmate Pramod invited me for his marriage on 1st May. Since it is a long trip of more than 24 hours from Pune to Kerala by bus, I thought I should plan some Free Software talk so that I have more motivation for such a hard trip. I was very happy to see great enthusiasm for gnome release party on my last visit.
Group Photo of Debian Utsavam participants
I asked a few people if it would be possible to organize something on such a short notice. I was happy to get a positive response and we fixed the event for 28th and 29th at MES college of Engineering, Kuttippuram. But I can reach there only on Sunday if I leave Pune on Friday and take one day transit in Bangalore (I take this option because I get to meet my friends during day and I have to travel only at night). I asked around if someone can volunteer to take some basics session on Saturday so that particiants will be ready for the packaging session on the next day.
Nakul readily volunteered to take command line and shell scripting sessions. Since Ershad was coming, he agreed to take Free Software introduction. I have to mention his great grassroots Free Software promotion work here. Though he doesn’t post much about it on smc or plus lists I came to know about it from people who attended the sessions. (A request to Ershad to blog and talk about it on mailing lists). Since Labeeb was also there in Kerala he agreed to introduce Debian.
Haris volunteered to take a session on building from source. He is very enthusiastic and he writes beautiful blogs. Read his account of the two days here.
Since I was not present on day 1 you can read about it from Haris’ blog. Raju sir told me I could stay with him and I went to his place directly on Sunday morning. I reached Mannuthi at 3.45 am and he picked me up. I slept a bit and after breakfast we came to MES. One thing I really liked there was the fluroscent moon and star (I guess there were planets too) stickers on the wall! You feel like you are watching the sky at night!
We reached MES by 10.20 and they had already started discussing about personal privacy and tracking on the internet. I started with reading a note I wrote the previous night in the bus.
Read the full note here.
I asked them about what they learned on the previous day and I asked them a few questions like why we need to package software, who creates packages etc. I started discussing basic ideas around a package’s lifecycle from upstream tarball to a stable release. A few points I covered include “how and when a package first enters debian. Concepts of RFP, package maintainer, team maintained packages etc were covered.”
There are many Free Software projects out there and role of a distribution like Debian is to provide a collection of these software in an easy to distribute and manage format. Distributions like debian make sure the software is in good condition and pass it through thorough testing before it is given out as a supported software. Since there are many distributions out there with different policies and packaging formats (deb, rpm, ebuilds etc). Also each of this distributions may be including different versions of its dependencies. So people specialising in packaging makes the job of upstream developers easier by making an easy to install version of the software available. Distributions include many Free Software but every day more Free Software is released. So who creates these debian packages? How does a person ready to create a package know there is a new software? What do one do when a software they need is not available as a package? How can one install such a software if it is not packaged?
Life cycle of a Software in Debian
Most Free Software projects release their work as a tarballs – a compressed file of all the source code with instructions to compile them. Many times people read about new software from news sites and some of them savvy enough start building it from source. If you are already familiar with development tools it may not be difficult to do. Some of those users may create a debian package. Sometimes people just request a software to be packaged. It is done by submitting a wishlist bug against ‘wnpp’ pseudo package. wnpp stands for Work Needing and Prosective Packages. Such requests for packages are commonly referred as RFPs. So there are two ways a package enters debian.
1. Some one who know about debian packaging creates a debian package from a source tarball provided by upstream developers.
2. Someone files an RFP in debian bug tracking system and people come to know about it via wnpp and then creates a package.
For small packages a single person may create a debian package alone and maintains it by providing newer packages when some bug is fixed or a new version is released. Sometimes there are many applications created by one project (eg GNOME, KDE) or packages are similar (for example packages written in one particular language like perl, python, ruby) or they are used in one particular area (for example software useful for medical doctors or useful in schools), in these situations a team maintains these packages.
I really like this team maintenance idea because you can help updating any package when you have time and other team members take care of it when you are busy. With teams distributed around the world most of the time there is someone available usually to take care of the packages. But more hands to help is always welcomed by the teams as it helps spread the load to more people and reduces work for each person.
“when does a package move to testing. Package priority and condition of release critical bugs were explained.”
All packages are normally uploaded to unstable branch. When a package is uploaded, their maintainer tells how important this upload is. For normal uploads a priority of ‘low’ is set and for critical fixes ‘medium’ and for security fixes ‘high’ priorities are used. Packages are kept for review in unstable branch for 10 days for low priority packages, 5 days for medium priority packages and 2 days for high priority packages.
Many people including this author use unstable distribution as their main operating system every day. When they encounter bugs they report them. I have to clarify what unstable means here, it means always changing and each software itself is stable (either the upstream developers or debian developers decide it is stable enough for every day use). For software which not stable for every day use experimental branch is used.
After 10, 5 or 2 days depending on package’s priority their status is checked (this is done by a software called britney) to see if they can be moved to testing branch. First condition it checks is if there is any release critical bug reported against this package. Second condition is its dependencies are already in testing. If both these conditions are met it will be moved to testing. So new packages keep coming to unstable and testing all the time except when testing is frozen for next release. So we can call both unstable and testing branches as rolling releases.
Every time a stable version is released goals for next stable release is set by the project after discussions with different teams. Each team may want a particular version of their software in the next release or project as a whole may decide on a new feature. These release goals are collected by release team and published early in the release cycle. When testing is very close to achieving these release goals release team declares testing is frozen.
At this point britney keeps all packages in unstable and only bug fixes are allowed into testing. Sometimes release team allows a few exceptions, but usually freeze time is spent on fixing bugs by all developers. When all release critical bugs are fixed in testing a copy of testing is released as stable. At this time normal movement of packages from unstable to testing is resumed and preparation for next stable release starts. Stable release is officially supported by the project and recieves security updates only, no new versions are uploaded into stable.
“when does it goes to stable. I told them about release goals and freeze. I told them we release when we are ready and that means zero release critical bugs.”
This time I did not take my favorite package lekhonee-gnome and instead I chose to introduce gem2deb tool. We took mixlib-log gem and easily created a deb file with just one command gem2deb mixlib-log. But there was a catch, they were running squeeze and gem2deb was not present in the normal repositories.
I just told them to install gem2deb, some people tried to install it from sid repo but failed matching correct dependencies (most of systems had a messed up sources.list file, presumably from yesterday’s apt session). Some figured they can install it from source and they downloaded gem2deb tarball from github and followed instructions in README file to build it. First application of what they learned yesterday. And dpkg-buildpackage -us -uc command given there came in very handy when they had to rebuild mixlib-log package.
Every one created a deb package with one easy command ‘gem2deb mixlib-log’. On some systems proxy was not set correctly so gem2deb could not download the gem file using ‘gem fetch mixlib-log’. So gem file was downloaded from rubygems.org and them gem2deb was run against this file.
Every one used lintian to check what is missing in packaging as per policy and they used help of New Maintainer’s Guide to fix those errors and warnings.
[TODO] chosing a new gem file to package or update to gem2deb based packaging.
(Posting it as incomplete, I may add more points and few more details later)
- Wiki page of the event
- Debian Handbook – a complete book on Debian
30/04/2012: First draft, outline
01/05/2012: Expanded on debian development stages
02/05/2012: added link to Haris’ blog, editing changes, splitted big paragraphs to small paragraphs.
03/05/2012: Link to the note I wrote added.
10/05/2012: Diagram from Debian Handbook describing the release process added.
PS: I think, I better make a book out of it because its going to be a big post otherwise 🙂
Note: I was just trying to dump my thoughts as I wrote this and I was in a hurry on the way to a friend’s wedding, plus it was typed in my almost-dead ‘first android phone’ my phone. So excuse if you see anything not in place. Thanks to Shirish for some corrections.
The amazing collaboration and enthusiasm showed by Swathanthra Malayalam Computing‘s (SMC) KDE subproject made this possible. We had to cross the kde essentials barrier, which is required for inclusion in a KDE release as a supported language in a very short span of time. We achieved this milestone by completing 10000+ strings in about 10 days by 30+ contributors. KDE essentials include the most important packages that a default installation will have including the libraries and the base applications. Other Indian languages to be supported in this release are Hindi, Tamil and Panjabi. Exciting thing about this milestone is the participation of people from all walks of life including students, farmers, scientist, engineers …
Some statistics here shows the progress of Malayalam translations in a week (during the most active week). Click to enlarge.
Many of us were working till 3-4 am in the morning for the entire week leading upto the 4.1 deadline on July 11. #smc-project on Freenode IRC was the main connection for realtime collaboration with ‘mandoos’ (an IRC bot who can learn maanings and teach anyone who asks for it) helping the newly joined members of the team. You can join the IRC channel using your web browser by following this link.
People from all over the globe and round the clock joined this effort. Some places to mention are Bengaluru, Pune, Chennai, Thiruvananthapuram, Kollam, USA … The enthusiam showed by the members throughout this great effort was amazing. In one single day 5 new contributors submited their first translation and more than 30 people contributed to this effort (Most of the contributors are listed here). It could be one of the few languages which completed kde essentials translations in such a short time.
You can see the list languages sorted by their percentatge of translations here. Malayalam is currently at 63rd position, 4th among Indian languages.
Here are some interesting screenshots of KDE 4.1 in Malayalam.
More screenshots from here.
I would like to thank the entire team for making this possible and do join us in the release party on Aug 9th and 10th at Thiruvananthapuram. Location and event schedule to be announced later (tune in to our mailing list for more details)
List of contributors. Thanks to Ani Peter for making this list.
1. Sasi Kumar
6. Prasad. S R
7. Hari Vishnu
16. Hiran Venugopalan
17. Hitha Venugopalan
21. Syam Krishnan
22. Shiju Alex
23. Ragsagar V
24. Maxin B John
25. Sarath Lakshman
26. Baiju. M
27. Joju Joshua
30. Rajiv and his Mandoos
KDE 4.1 Release Notes – Malayalam English