New DJBDNS

Hi,

Today, I present to you New DJBDNS. A brand New release of the DJBDNS.

    See N-DJBDNS

I never thought I’d write this, but it is with extreme pleasure that I invite you to try,

    # yum install ndjbdns
Yes! N-DJBDNS – is an official Fedora package…YAY!!! 🙂

A packaging exercise which began more than three years ago, has finally come to an end. When it was approved, I spent some time reading all the comments that were posted on this review request. The very first one from Ralf Corsepius said


   This package will need a lot of love to let it pass a review.

I knew it was going to be tough, everybody said that. But honestly, I never imagined three years. It feels awesome today! 🙂

Feels awesome, not only because it is over, but also because it’s the new beginning. Now I can focus on further development and renovation. There’s a long list of things yet to be done. For N-DJBDNS to be more useful, concise, independent and maintainable in the long run, in the near future it needs to,

  • Apply existing patches which are not yet included in the current source. This is going to be tricky, because the original patches were not created for the current source tree. It’s going to be a lot of manual work to apply them.
  • Write good user manuals and online documentation for each of the tools. It could be like an E-book, with one chapter dedicated to each tool.
  • To perform rigorous testing of the individual tools on Linux, *BSD platforms.
  • Format the sources for more readability and hacking comfort. This might sound mundane and boring, but in the long run, I think it is just as important as fixing a security bug. I’ve done close to 50/204 files so far. I could definitely use a little help here.
  • Remove redundant source files.

If you think you could help with any of these tasks, please drop me a mail. I would more than appreciate it and would be glad to work with you. There are many individual tasks which are very good for summer projects and assignments.

If you have any comments, suggestions or if you find any bug in the current release, please feel free to write to me or raise an issue on github. I’ll do my best to address such issues.

I hope you find it useful. 🙂

PS: My sincere thanks to Rahul, Satya, Kushal and Rakesh for all your help.

Of Django-south migrations

Last week at work I stumbled upon this problem: two of the Django-south migrations made conflicting changes to the database schema. Let’s say 0003_migration_1 & 0003_migration_2 are the two migrations applied in the same order. But, the models in migration_2 do not include the changes made by migration_1.

This causes a problem while creating a new migration

   $ python manage.py schemamigration my_app –auto [–stdout]

creates a new migration: 0004_migration_1. While creating this new migration, Django-south does a diff(1) between the current models definition and the one in the last applied migration ie: 0003_migration_2. But since 0003_migration_2 did not include the model changes from 0003_migration_1, the new migration: 0004_migration_1 includes those changes. And when you try to apply this new migration

   $ python manage.py migrate my_app

it causes an error wherein Django-south says that some of the database changes already exist in the database.

Now one solution, though not so straightforward, is to manually merge the two migrations: 0003_migration_1 and 0003_migration_2, so that the resulting new migration script combines the two model definitions.

Thankfully, Django-south has a way to create empty migrations and freeze the models definition. Empty migrations don’t make any schema chagnes, but only store the updated model definitions.

   $ python manage.py schemamigration –freeze=my_app –empty –auto [–stdout]

creates a new migration 0004_empty_migration_1, which holds the latest model definitinons, ie changes made by 0003_migration_1 and 0003_migration_2 together into one. After applying the empty migration, I could create the new migration: 0005_migration_1 to include just the new schama changes and exclude the ones which were already applied by previous migrations.

* Tip: use –stdout option to see and verify the schema changes included in the new migration.