Part 1 of a 3 part series of blog posts on celebrating Software Freedom Day (SFD) at Mumbai, Directiplex on 19th September 2015.

Just few days after the Trip to Chandigarh, this time we thought of celebrating Software Freedom Day at Mumbai as well. I had been concerned as the day before it rained quite heavily in Pune, called up people and came to know that Mumbai was dry. Hence started pretty early in the morning (around 0600 hrs) from home, went to the Pune Station to be told that some rails between Khandala and Karjat had come off and hence only a single route was working and it was imperative to give priority to long-distance trains. Thinking for a while and finally boarded a Shivneri (Government A/C Volvo buses which travel to and fro between Pune and Mumbai and other places in Maharashtra) for Mumbai. Reached the Venue around 11:00 and came to know that due to time-rescheduling it was about to begin. As I had just come in, I needed some time to settle in, had some water, re-freshed myself and had a cup of tea and then was able to be up for the presentation.

Clarification – By newbies I simply mean new people, it means people who are either new to the process, in this case the Debian project as well as people who are completely new to this sort of way/working. It isn’t meant to discourage people in anyway, even today I still feel that I’m a newbie as I discover Debian more and more and free software at general. It never ceases to amaze me how few people are changing an entire way of working (for the better 🙂 ) .

In the brief time before I started, I understood that these were very raw students, most of them have heard the word open-source maybe for the very first time. So Obviously I had to make it accessible to newbies, thankfully the presentation was cut to 30 minutes, as very few people had either Debian or Ubuntu installed on their lappies which was a requirement for the talk/presentation. This is more easily said then done because the topic I had chosen was a technical one, “Reporting & Triaging Bugs Using Reportbug” . It would have been more fun if people were a bit more tech-savvy as would have had the pleasure of also going through triaging bugs with them and the tools used therein.

To share it in brief, all and any software goes through what is called QA (Quality Assessment) but due to budgetary and other constraints not all use-cases and combinations of software are tested out. This is true for any software out there. So, there needs to be a way for users of the software to reach out to the developer to point out any inadvertent errors that s/he might have made while developing as well as to ask for new features as well. In order to do so, you have reporting tools which are used by various projects, people etc. Some of them are web-based while others use more traditional ways which gives some contextual information about where and what the bug occurred is.

…there needs to be a way for users of the software to reach out to the developer to point out any inadvertent errors that s/he might have made while developing as well as to ask for new features as well.


So, as most students were newbies, shared some use-cases as to why bug-reporting tools are necessary, while it is a bug-reporting tools, at times it is also used to discuss policy matters and other things. But as these were newbies, just shared about the technical merits of having a good reporting tool. As I am and have been using Debian, shared about reportbug. An equivalent tool is Ubuntu is apport but there are quite a few differences in the tools and the way it is processed, although AFAI remember, both tools are python-based. Reportbug I know for sure, apport I am not so sure but do remember it was python-based all those years back.

Anyways, as I had expected people to be somewhat technically competant, I had purged reportbug at my end.

I skipped the long-reading of the package description as it goes to much depth then is desirous for a newbie audience.

Description: reports bugs in the Debian distribution

As had just come, didn’t know if the organizers had made some network access (SSID) for us or not but as had purged reportbug with the knowledge that it is there in my local archive. In fact, in Debian if you purge any package it is just removed from the packages that you are using but are still retained at /var/cache/apt/archives . If you remove it from there then you need network access or if the package has become obsolete and you have used autoclean.

From aptitude’s manual –

autoclean : Removes any cached packages which can no longer be downloaded. This allows you to prevent a cache from growing out of control over time without completely emptying it.

So started the re-installation of the tool mid-way through the presentation. While installing it though, hit a bug which I later realized was actually not due to reportbug but apt-list bugs which is another tool I use. Anyways, reported the bug as and as can be seen Franscesca Poli answered it the very next day. This shows the vibrancy of the Debian project on which hamara would be based as well as systems and tools that the Debian project has made (which should be emulated) so Debian Maintainers and Developers do respond in time, although it is pretty much still an individual or a team thing.

Anyways, I started to configure it as was short of time , if I had a bit more time, I would have gone through the man page of reportbug.conf which outlines the various options that a user could use. In hindsight, I wish I really had more time and had shown them how each option changed, but as time was the enemy, barely had enough time to install, configure and report the bug I have shared above in the debian BTS that they were shout for lunches and I knew I had lost the audience 🙂 I quickly wrapped up the session and we all went to have lunch.

Shirish sharing about the Debian BTS