ubuntu – Page 3 – Nigel Babu

Amazon RDS Timezone Hack

‘Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while managing time-consuming database administration tasks, freeing you up to focus on your applications and business.’ – Amazon RDS Website

Amazon RDS uses UTC by default. Personally, I think systems should use UTC by default, but at my work place, all systems are in IST, which means we want the RDS to work in IST too. So, we have this hack of setting the init_connect parameter to set time_zone = 'Asia/Kolkata';. This works great, except when you have to restart RDS. We’ve had to restart our instance twice so far, both times leading to considerable downtime, pain, and grief because of this hack (thankfully, the RDS machine is a backup machine and not used in production).

When it happened the first time, my ex-colleague did the modification and all I did note down was to remove the init_connect parameter. When it happened the second time, I remembered and set the init_connect parameter to an empty string, which I thought would work. Unfortunately, it didn’t. We talked to Amazon Support and now I know that when it happens, I should not be setting it to an empty value, but resetting instead.

rds-reset-db-parameter-group my-params --parameters 'name=init_connect,method=immediate'

This post is for all those poor souls who might make the same mistake as me as well as a note to myself (though I suspect I’ll never forget this lesson :P) 🙂

RTFD and Summit

Writing documentation isn’t easy. And maintaining up-to-date documentation isn’t easy either. readthedocs.org is a Django project which was written as part of Django Dash It is backed by RevSys, Python Software Foundation, and Mozilla Webdev. We can write our docs in Sphinx and import it into Read the Docs.

I’ve just got it setup for summit. New contributors to Summit can see its developer documentation at summit.rtfd.org

Summit improvements and bug fixes

‘If I do that, I might break Summit!’

That’s something often heard at UDSes by organizers. Indeed, Summit has historically had stability issues, especially during the high-usage week of a UDS. But Summit is starting to outgrow it’s troubled youth, gaining better code, better testing, and most importantly, more stability.

The Summit team, consisting of Michael Hall, Chris Johnston, and I, has been hacking on Summit much more this cycle than ever. We even had a few new contributors this cycle. Our focus this cycle was to make it more stable first, and then more usable. There are lots of UI fixes that people have requested. We only haven’t gotten to them because we want Summit to be very stable this cycle. If you’d like to help us make Summit more awesome, please file bugs on things that you think Summit should do or places were Summit sucks. We can’t promise anything, but its great to nail down things we should fix.

The Summit team has fixed a whole bunch of bugs this cycle. Big shout out to Chris Johnston and Michael Hall for setting the speed of development early on. Before I reached home back from UDS, there were I think 4 MPs for Summit (!?!). We’d also like to thank Maris Fogel for helping us setup a test framework. We’d like Summit to be more stable and having unit tests drives us in this direction.

We’ve been busying making Summit much more awesome!

Lighting Talks at UDW

Since the last Ubuntu Developer Week, we’ve been having a session dedicated to project lighting talks, if you have an interesting project that you’re working on, talk about it for 5 minutes. Show case your project and maybe ask for new contributors in this quick 5 minutes per project session! If you’re interested, please add your name and project name to the Lightning Talks page or come find me in #ubuntu-devel or #ubuntu-motu and let me know. I’ll add you to the list!

Fix FTBFS Jam

As of me writing this post, there are about 428 packages that have failed to build from source (FTBFS)]. We’re doing a FTBFS jam this Wednesday (29 June, 2011). If you’re interested in helping out, drop by in #ubuntu-motu) and just generally say that you want to help fix FTBFS and someone will be able to guide you. We have a list of packages that are potential targets to be fixed.

While we won’t try to fix everything, we’ll be focusing on specifc failures, the ones caused by toolchain changes. Ubuntu is changing the way it handles shared library linking. Similar changes are also happening in Debian.

Before I get into spare details of the reason for these build failures, I’d like to emphasise that the failures that we’re targetting to fix are quite easy and just needs some tinkering with make files. I recently fixed a build failure in the redis package. Take a look at the build log of the failure, the patch that fixed it, and the build log after the fix.

Cause of the failure

For more information on fixing these failures, please see the Ubuntu wiki page and the Debian wiki page.

Previously, the linker (ld) would allow indirect linking of shared library symbols. For example, if you had a function spin in the library libwheel, and the library libcar used libwheel, then a program that used libcar would have the ability to call spin even though it never directly used libwheel. This kind of indirect linking leads to fragile code; when the dependency chain of a shared library changes, it can break the program that used it.

ld now runs with the --no-copy-dt-needed-entries option enabled by default. This option is also sometimes called --no-add-needed. This means that, in the example above, the spin function would only be available when libwheel was directly linked by adding -lwheel to the command-line compiler flags, and not available indirectly through libcar. Also, ld runs with the --as-needed option enabled by default. This means that, in the example above, if no symbols from libwheel were needed by racetrack, then libwheel would not be linked even if it was explicitly included in the command-line compiler flags.

The solution to a build error caused by indirect linking, is to directly link all needed libraries in the compiler flags on the command-line. For example, if you were previously linking with -lcar -ltruck, you would now need to explicitly add -lwheel. For example:

gcc -Wall racetrack.c -lcar -ltruck -lwheel -o racetrack

The --as-needed option also makes the linker sensitive to the ordering of libraries on the command-line. You may need to move some libraries later in the command-line, so they come after other libraries or files that require symbols from them. For example, the following link line is wrong, and needs to be changed so that libraries come after objects that use them:

gcc -Wall -lwheel -lcar -ltruck -o racetrack racetrack.c

When problems result from the --no-copy-dt-needed-entries option, the linker will always give you a hint at the right fix in the error message, for example ‘try adding it to the linker command line’.