Five years ago Debian and most derivatives switched from the standard GNU C Library (GLIBC) to the Embedded GLIBC (EGLIBC). Debian is now about to take the reverse way switching back to GLIBC, as EGLIBC is now a dead project, the last release being the 2.19 one. At the time of writing the glibc package has been uploaded to experimental and sits in the NEW queue. EGLIBC is dead for a good reason: the GLIBC development has changed a lot in the recent years, due to two major events: Ulrich Drepper leaving Red Hat and the GLIBC development, and the GLIBC steering committe self-dissolving. This has resulted in a much more friendly development based on team work with good cooperation. The development is now based on peer review, which results in less buggy code (humans do make mistakes). It has also resulted in things that were clearly impossible before, like using the same repository for all architectures, and even getting rid of the ports/ directory. Before we used to have two sets of architectures, the main ones in the glibc repository with architectures like x86, SuperH or SPARC, and the secondary ones in the glibc-ports repository with architectures like ARM or MIPS. As you can see the separation was quite arbitrary, and often leaded to missing changes on the secondary architectures. We also got real stable branches, with regular fixes. The most important EGLIBC features have been merged to GLIBC, including for example the use of non-bash but POSIX shell, or the renaming of reserved keywords. The notable exception is the support for configurable components, which we originally planned to use for Debian-Installer, by building a smaller flavor using -Os and without NIS and RPC support. At the end we never worked on that, and it seems that the hardware targeted by Debian has grown faster than the GLIBC size, so that is not really a big loss. At the end, we ended up with only 5 missing patches from the EGLIBC tree:

• Installation of *_pic.a files for use of mklibs in debian-installer
• Dynamic reload of /etc/resolv.conf
• Installation of headers during bootstrapping
• Workarounds for PowerPC 8xx CPUs
• Access to FPSCR on SH4

The package names are unchanged (except the source package and the binary package containing the sources) so the transition is fully transparent for the users. I would like to thank all the CodeSourcery employees who worked on EGLIBC, with a special thank to Joseph Myers who spent countless hours to merge the most important EGLIBC changes back to GLIBC, and sent regular emails about the merge status. I would also like to thanks all the people on the GLIBC side that made the change to happen, and all persons participating in the GLIBC development.

It is time for a new Tanglu update, which has been overdue for a long time now! Many things happened in Tanglu development, so here is just a short overview of what was done in the past months. Infrastructure Debile The whole Tanglu distribution is now built with Debile, replacing Jenkins, which was difficult to use for package building purposes (although Jenkins is great for other things). You can see the Tanglu builders in action at buildd.tg.o. The migration to Debile took a lot of time (a lot more than expected), and blocked the Bartholomea development at the beginning, but now it is working smoothly. Many thanks to all people who have been involved with making Debile work for Tanglu, especially Jon Severinsson. And of course many thanks to the Debile developers for helping with the integration, Sylvestre Ledru and of course Paul Tagliamonte. Archive Server Migration Those who read the tanglu-announce mailinglist know this already: We moved the main archive server stuff at archive.tg.o to to a new location, and to a very powerful machine. We also added some additional security measures to it, to prevent attacks. The previous machine is now being used for the bugtracker at bugs.tg.o and for some other things, including an archive mirror and the new Tanglu User Forums. See more about that below Transitions There is huge ongoing work on package transitions. Take a look at our transition tracker and the staging migration log to get a taste of it. Merging with Debian Unstable is also going on right now, and we are working on merging some of the Tanglu changes which are useful for Debian as well (or which just reduce the diff to Tanglu) back to their upstream packages. Installer Work on the Tanglu Live-Installer, although badly needed, has not yet been started (it s a task ready for taking by anyone who likes to do it!) however, some awesome progress has been made in making the Debian-Installer work for Tanglu, which allows us to perform minimal installations of the Tanglu base systems and allows easier support of alternative Tanglu falvours. The work on d-i also uncovered a bug which appeared with the latest version of findutils, which has been reported upstream before Debian could run into it. This awesome progress was possible thanks to the work of Philip Mu kovac and Thomas Funk (in really hard debug sessions).
Tanglu Forums We finally have the long-awaited Tanglu user forums ready! As discussed in the last meeting, a popular demand on IRC and our mailing lists was a forum or Stackexchange-like service for users to communicate, since many people can work better with that than with mailinglists. Therefore, the new English TangluUsers forum is now ready at TangluUsers.org. The forum software is in an alpha version though, so we might experience some bugs which haven t been uncovered in the testing period. We will watch how the software performs and then decide if we stick to it or maybe switch to another one. But so far, we are really happy with the Misago Forums, and our usage of it already led to the inclusion of some patches against Misago. It also is actively maintained and has an active community. Misc Things KDE We will ship with at least KDE Applications 4.13, maybe some 4.14 things as well (if we are lucky, since Tanglu will likely be in feature-freeze when this stuff is released). The other KDE parts will remain on their latest version from the 4.x series. For Tanglu 3, we might update KDE SC 4.x to KDE Frameworks 5 and use Plasma 5 though. GNOME Due to the lack manpower on the GNOME flavor, GNOME will ship in the same version available in Debian Sid maybe with some stuff pulled from Experimental, where it makes sense. A GNOME flavor is planned to be available. Common infrastructure We currently run with systemd 208, but a switch to 210 is planned. Tanglu 2 also targets the X.org server in version 1.16. For more changes, stay tuned. The kernel release for Bartholomea is also not yet decided. Artwork Work on the default Tanglu 2 design has started as well any artwork submissions are most welcome! Tanglu joins the OIN The Tanglu project is now a proud member (licensee) of the Open Invention Network (OIN), which build a pool of defensive patents to protect the Linux ecosystem from companies who are trying to use patents against Linux. Although the Tanglu community does not fully support the generally positive stance the OIN has about software patents, the OIN effort is very useful and we agree with it s goal. Therefore, Tanglu joined the OIN as licensee.

---

And that s the stuff for now! If you have further questions, just join us on #tanglu or #tanglu-devel on Freenode, or write to our newly created forum! You can, as always, also subscribe to our mailinglists to get in touch.

AddThis:

Categories:

• Debian-Blog
• Technology
• Tools

Keywords:

• laptop-mode-tools

Yesterday, the Belgian team played against Algeria, and won 2-1. Before the match, there was some criticism about coach Wilmots' decision not to field a number of top players in the team at the start of the match. Today, some journalists -- including, apparently, some Russian journalists -- seem to think that the team didn't play all that well, and that the Belgian team could be beaten by a better team. I don't think that's the case; I think the strategy of Wilmots was a stroke of genius. The Algerian coach fielded a wall of 5 defenders, and played a pretty good counter game. When the Belgian team had posession -- for about 65% of the time during the entire match -- the Algerians returned every man to their own half of the field. Whenever one of the Belgian strikers came close to the Algerian penalty area, at least two Algerian players would be near and block them off. How does one win from a team that doesn't want to give you a millimeter of room? One way is to wear them out, and that's exactly what the team did: by keeping the pressure on the Algerian defense, the Algerian defense had to run a lot. Running a lot makes you tired, and if you're tired you make mistakes, or you can't follow a fresh substitute player. During half-time, it was reported that Wilmots had relayed the message to his players that "the bench will make the difference". And indeed it did; some time into through the second half, Wilmots substituted three players -- two strikers and one offensive midfielder -- with the top players he'd kept on the bench. Two of these three players made the difference, scoring two goals to end up with 2-1. Reading some articles today, it seems like many analysts think that this was a spur of the moment thing by Wilmots; but I think it's more likely that this was a deliberate strategy. Making the opposing defense run a lot is certainly a good strategy; but the downside of that is that your own offensive players will need to run a lot, too. If you can swap those out for top players on the bench... It'll be interesting to see the next matches.

TeleGPS Battery Life I charged up one of the 160mAh batteries that we sell. (The ones we ve got now are labeled 200mAh; the 160mAh rating is something like a minimum that we expect to be able to ever get at that size.) I connected the battery to a TeleGPS board, hooked up a telemetry monitoring setup on my laptop and set the device in the window of my office. This let me watch the battery voltage through the day without interrupting my other work. Of course, because the telemetry was logged to a file, I ve now got a complete plot of the voltage data: It looks like a pretty typical lithium polymer discharge graph; slightly faster drop from the 4.1V full charge voltage down to about 3.9V, then a gradual drop to 3.65 at which point it starts to dive as the battery is nearly discharged. Because we run the electronics at 3.3V, and the LDO has a dropout of about 100mV, it s best if the battery stays above 3.4V. That occurred at around 21500 seconds of run time, or almost exactly six hours. We also have an 850mAh battery in the shop; I d expect that to last a bit more than four times as long, or about a day. Maybe I ll get bored enough at some point to hook one up and verify that guess.

The Debian Edu / Skolelinux project provide an instruction manual for teachers, system administrators and other users that contain useful tips for setting up and maintaining a Debian Edu installation. This text is about how the text processing of this manual is handled in the project. One goal of the project is to provide information in the native language of its users, and for this we need to handle translations. But we also want to make sure each language contain the same information, so for this we need a good way to keep the translations in sync. And we want it to be easy for our users to improve the documentation, avoiding the need to learn special formats or tools to contribute, and the obvious way to do this is to make it possible to edit the documentation using a web browser. We also want it to be easy for translators to keep the translation up to date, and give them help in figuring out what need to be translated. Here is the list of tools and the process we have found trying to reach all these goals. We maintain the authoritative source of our manual in the Debian wiki, as several wiki pages written in English. It consist of one front page with references to the different chapters, several pages for each chapter, and finally one "collection page" gluing all the chapters together into one large web page (aka the AllInOne page). The AllInOne page is the one used for further processing and translations. Thanks to the fact that the MoinMoin installation on wiki.debian.org support exporting pages in the Docbook format, we can fetch the list of pages to export using the raw version of the AllInOne page, loop over each of them to generate a Docbook XML version of the manual. This process also download images and transform image references to use the locally downloaded images. The generated Docbook XML files are slightly broken, so some post-processing is done using the documentation/scripts/get_manual program, and the result is a nice Docbook XML file (debian-edu-wheezy-manual.xml) and a handfull of images. The XML file can now be used to generate PDF, HTML and epub versions of the English manual. This is the basic step of our process, making PDF (using dblatex), HTML (using xsltproc) and epub (using dbtoepub) version from Docbook XML, and the resulting files are placed in the debian-edu-doc-en binary package. But English documentation is not enough for us. We want translated documentation too, and we want to make it easy for translators to track the English original. For this we use the poxml package, which allow us to transform the English Docbook XML file into a translation file (a .pot file), usable with the normal gettext based translation tools used by those translating free software. The pot file is used to create and maintain translation files (several .po files), which the translations update with the native language translations of all titles, paragraphs and blocks of text in the original. The next step is combining the original English Docbook XML and the translation file (say debian-edu-wheezy-manual.nb.po), to create a translated Docbook XML file (in this case debian-edu-wheezy-manual.nb.xml). This translated (or partly translated, if the translation is not complete) Docbook XML file can then be used like the original to create a PDF, HTML and epub version of the documentation. The translators use different tools to edit the .po files. We recommend using lokalize, while some use emacs and vi, others can use web based editors like Poodle or Transifex. All we care about is where the .po file end up, in our git repository. Updated translations can either be committed directly to git, or submitted as bug reports against the debian-edu-doc package. One challenge is images, which both might need to be translated (if they show translated user applications), and are needed in different formats when creating PDF and HTML versions (epub is a HTML version in this regard). For this we transform the original PNG images to the needed density and format during build, and have a way to provide translated images by storing translated versions in images/$LANGUAGECODE/. I am a bit unsure about the details here. The package maintainers know more. If you wonder what the result look like, we provide the content of the documentation packages on the web. See for example the Italian PDF version or the German HTML version. We do not yet build the epub version by default, but perhaps it will be done in the future. To learn more, check out the debian-edu-doc package, the manual on the wiki and the translation instructions in the manual.

I used to work for Bytemark, being a sysadmin and sometimes handling support requests from end-users, along with their clients. One thing that never got old was marking DNS-related tickets as "resolved", or managing to slip that word into replies. Similarly being married to a Finnish woman you'd be amazed how often Finnish and Finished become interchangable. Anyway that's enough pun-discussion. Over the past few days I've, obviously, been playing with DNS. There are two public results:

DHCP.io

This is my simple Dynamic-DNS host, which has now picked up a few users. I posted a token on previous entry, and I've had fun seeing how people keep changing the IP address of the host skx.dhcp.io.. I should revoke the token and actually claim the name - but to be honest it is more fun seeing it update. What is most interesting is that I can see it being used for real - I see from the access logs some people have actually scheduled curl to run on an hourly basis. Neat.

DNS-API.org

This is a simple lookup utility, allowing queries to be made, such as:

• http://dns-api.org/a/skx.dhcp.io
• http://dns-api.org/aaaa/skx.dhcp.io

Of the two sites this is perhaps the most useful, but again I expect it isn't unique.

That about wraps things up for the moment. It may well be the case that in the future there is some Git + DNS + Amazon integration for DNS-hosting, but I'm going to leave it alone for the moment. Despite writing about DNS several times in the past the only reason this flurry of activity arose is that I'm hacking some Amazon & CPanel integration at the moment - and I wanted to experiment with Amazon's API some more. So, we'll mark this activity as resolved, and I shall go make some coffee now this entry is Finnish. ObRandomUpdate: At least there was a productive side-effect here - I created/uploaded to CPAN CGI::Application::Plugin::Throttle.

I've never liked the contents of the bash-completion package. I've found its results to be confusing, mildly buggy, and therefore terribly annoying. As such, for the longest time, one of the first things I used to do when installing a new system was to just remove it entirely -- or add "complete -r" or similar to my .bashrc on systems where I did not have sysadmin powers. However, that's not to say that I don't understand the reason for programmable completion. Filename completion is nice, but it's great if one can have things like command option completion, etc. As such, I've resolved to give the bash-completion another shot for, say, a month or so, and to actually file bugs when things happen that I think should not. Of course, it's very well possible that in the time since I last tried it, all those annoyingly small confusing bugs have been fixed. But somehow, I doubt that. I guess we'll find out.

So, after writing my last blog post in frustration, several people knowing their way around Tor better than me wrote that I should just configure my machine not to be an exit relay, but a middle relay or a bridge. So, I set it up to be a bridge about five days ago. And, as they pointed out, I have not experienced any problems. Interesting: The traffic pattern is very different. Compare: Traffic pattern as an exit relay:
Traffic pattern as a bridge:
Anyway I'm happy to have Lobazal back online!

Another relative with cancer. Another very short haircut in sympathy.

Maybe someone else is using iDataPlex HW, so this might come in helpful... TL, DR: Dear Hardware Vendors! Please don't force people to use specific Linux distributions when a simple unzip command would do the same. At work we run (amongst others) an HPC system consisting of 120 IBM System X iDataPlex dx360 M4 Nodes. Recently, after some MCE logs caused by DIMM errors, the IBM guy refused to send me replacement DIMMs if if didn't update IMM firware and tortue test the machine some days more. Well, ok... IBM uses the so called UpdateXpress tool to update IMM and UEFI firmware. The tool is available for rhel4 to rhel7 (both 32 and 64 bit), SLES10 & SLES11 and Microsoft Windows. I tried all of the available UpdateXpress System Pack Installers, with basically the same result everytime:

WARNING! This package doesn't appear to match your system.
         The following information was determined for your system:
           distribution = Unknown
           release = -1
           processor architecture = Unknown

I tried to set up a fake RHEL environment (customized /usr/local/uname, custom /et/RHel-release, etc...) but after some more tries, the installer (yes, it's still the installer I am trying to run) fails with some strange SEGFAULTS. After some closer inspection, (well, the RHEL4 uxspi binary is about 109MB big!) i tried to unzip it, and voila:

~/firmware$ unzip ibm_utl_uxspi_9.60_rhel4_32-64.bin
Archive:  ibm_utl_uxspi_9.60_rhel4_32-64.bin
   creating: rhel6_64/image/
  inflating: rhel6_64/image/libpegasus.nsp.so  
  inflating: rhel6_64/image/libUxliteImmUsbLan.so  
  inflating: rhel6_64/image/eccConnect.properties  
  inflating: rhel6_64/image/libpegslp_client.so  
   creating: rhel6_64/image/esxi_assoc_templates/
  inflating: rhel6_64/image/esxi_assoc_templates/elxFC.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/elxCNA.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/ibmc.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/FPGA-S.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/degraded.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/brocadeFC.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/qlgcFC.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/broadcom.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/LSI.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/brocadeCNA.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/uefi.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/diags.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/qlgcCNA.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/VMwareESXi.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/ibmc2.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/FPGA.uxt  
  inflating: rhel6_64/image/libipmi_client.so  
  inflating: rhel6_64/image/UXLite_UPDATEID.dat  
  inflating: rhel6_64/image/libacpi.so  
  inflating: rhel6_64/image/libibmsp6_openipmi.so  
  ...

I managed to find a iflash64 binary, and after so trial and error, came up with the following workflow:

• Unzip the .uxz firmware file (you get this from the IBM Download Central):

  unzip ibm_fw_imm2_1aoo56d-3.73_anyos_noarch.uxz
  Archive:  ibm_fw_imm2_1aoo56d-3.73_anyos_noarch.uxz
  replace imm2_1aoo56d-3.73.upd? [y]es, [n]o, [A]ll, [N]one, [r]ename: A
   extracting: imm2_1aoo56d-3.73.upd
    inflating: immalert.mib
    inflating: immRegistries.zip
    inflating: imm.mib
    inflating: OpenSourceNotices.html
    inflating: payload.xml
  

• Run the iflash tool:

./iflash64 --host your_host_imm_IP --user your_username --password your_password --package imm2_1aoo56d-3.73.upd --reboot
IBM Command Line IMM Flash Update Utility v2.02.11
Licensed Materials - Property of IBM
(C) Copyright IBM Corp. 2009 - 2014  All Rights Reserved.
Connected to IMM at IP address x.x.x.x.
Update package firmware type: IMM2
Update package build level:   xxxxxx
Target's current build level: xxxxxx
Would you like to continue with the update? y/n: y
Node 0: The IMM is preparing to receive the update.
Node 0: Transferring image: 98%
Node 0: Transfer complete.
Node 0: Validating image.
Node 0: Updating firmware:  0%
Node 0: Updating firmware:  100%
Node 0: Update complete.
Performing activation of the firmware:
Connected to IMM at IP address 10.8.2.4 successfully.
..........
Waiting up to 360 seconds for the activation to complete:
..
..

And so on... Conclusio: Dear Hardware Vendors! Please don't force people to use specific Linux distributions when a simple unzip command would do the same.

Fear of losing If I am afraid of breaking my laptop, then I may leave it at home, and it will be as if I didn't have a laptop. If I am afraid of losing faith, then I may closely follow the dictates of the church. I will be keeping the church's faith, but not mine. If I am afraid of losing my children, they may have to run away from me to be free to grow into adults. If I am afraid of losing my inner child, then I might not expose it to the world, and so my inner child will never live. I will just be a box, a mask of what the world expects from me, that shelters and cages the Me that would like to live. If I am afraid of losing you, then I may get obsessed with preserving the beautiful image I have of you. I may stop seeing, experiencing you as you live, think, grow. I may become afraid of your depth, of your being different each day, of your being alive. I may end up with cherishing a perfect image of you in my head, while you will have become a stranger to me. I am really asking when I can accept answers. I am really living when I can accept myself. I am really loving when I can accept you.

AltOS 1.4 TeleGPS support, features and bug fixes Bdale and I are pleased to announce the release of AltOS version 1.4. AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software. This is a major release of AltOS, including support for our new TeleGPS board and a host of new features and bug fixes AltOS Firmware TeleGPS added, new features and fixes Our new tracker, TeleGPS, works quite differently than a flight computer

• Starts tracking and logging at power-on
• Disables RF and logging only when connected to USB
• Doesn t log position when it isn t moving for a long time.

TeleGPS transmits our digital telemetry protocol, APRS and radio direction finding beacons. For TeleMega, we ve made the firing time for the additional pyro channels (A-D) configurable, in case the default (50ms) isn t long enough. AltOS Beeping Changes The three-beep startup tones have been replaced with a report of the current battery voltage. This is nice on all of the board, but particularly useful with EasyMini which doesn t have the benefit of telemetry reporting its state. We also changed the other state tones to Farnsworth spacing. This makes them all faster, and easier to distinguish from the numeric reports of voltage and altitude. Finally, we ve added the ability to change the frequency of the beeper tones. This is nice when you have two Altus Metrum flight computers in the same ebay and want to be able to tell the beeps apart. AltOS Bug Fixes Fixed a bug which prevented you from using TeleMega s extra pyro channel Flight State After configuration value. AltOS 1.3.2 on TeleMetrum v2.0 and TeleMega would reset the flight number to 2 after erasing flights; that s been fixed. AltosUI New Maps, igniter tab and a few fixes With TeleGPS tracks now potentially ranging over a much wider area than a typical rocket flight, the Maps interface has been updated to include zooming and multiple map styles. It also now uses less memory, which should make it work on a wider range of systems. For TeleMega, we ve added an Igniter tab to the flight monitor interface so you can check voltages on the extra pyro channels before pushing the button. We re hoping that the new Maps interface will load and run on machines with limited memory for Java applications; please let us know if this changes anything for you. TeleGPS All new application just for TeleGPS While TeleGPS shares the same telemetry and data logging capabilities as all of the Altus Metrum flight computers, its use as a tracker is expected to be both broader and simpler than the rocketry-specific systems. We ve build a custom TeleGPS application that incorporates the mapping and data visualization aspects of AltosUI, but eliminates all of the rocketry-specific flight state tracking.

While not required by Debian policy, the patch tagging guidelines (aka DEP-3) recommends to add a structured header to source package patches. Long story short, patches should begin with something like :

Description: tweak lcdproc config for debian
patch LCDd.conf to:
* use syslog instead of stderr to show message
* run LCDd as root (to read /dev/lcd* file)
.
The latter could be done better by tweaking udev rule
Author: dod
Applied-Upstream: NA

Making sure that the DEP-3 recommendation is respected may not be fun. Do not despair: once libconfig-model-dpkg-perl is installed on your system, you can check whether your patches respect the DEP3 recommendation with the following command: $ cme check dpkg-patches
loading data
checking data
check done You can also check individual patches with: cme check dpkg-patch tweak-conf Note that bash auto-completion is provided only from version 2.049 of libconfig-model-dpkg-perl package. If editing the header of your patches with your favorite editor does not strike you as fun, you can also use cme graphical editor provided by libconfig-model-tkui-perl. Once this package is installed, you can run: cme edit dpkg-patches You will get this editor to update your patches: This editor will show you the available parameters and the associated documentation to let you provide relevant information. Last but not least, patch header check is also performed when you check your whole package with cme check dpkg All the best
Tagged: Config::Model, debian, package, patch

Warning: some spoilers ahead. A few months ago I saw the trailer for Edge of Tomorrow (film). Normally I don't look for trailers, probably this was shared on G+ by someone; but the basic idea behind the trailer was interesting enough I tried to look for more information about the (then upcoming) movie. To my surprise, I learned that this Hollywood movie is based on a Japanese novel - All You Need Is Kill. Since (broadly speaking) Japanese style is quite different from Hollywood style, I became even more interested. So I bought the book, and went through it quite quickly - I liked it a lot, and for the most part is has kept me reading and reading. I would say the book is quite straightforward, with a bitter-sweet ending that is what I (dreaded and) expected from it. Fast forward a few months, and yesterday I saw the movie. I had somewhat lower expectations for it compared to the book, but I was surprised at how they managed to morph the Japanese setting in the book into an European one and give a good introduction into the plot. The downside is that they had to make it somewhat melodramatic here and there, and that they added quite a bit of extra plot to fill in the time; on the other hand, it skipped a lot of background detail that the book brought and which explains the setting of the war. The biggest change however was to the overall plot line: the book is only about a single battle, and makes it clear at the end that the war is far from over. The movie, in grand Hollywood style, solves the entire war in one neat swipe, and has a quite happy ending. Which is not bad per se, but doesn't have the same emotional impact as the book. Oh, and they made the aliens scarier but in a strange way prettier (or better said less alien). Interesting that they felt the need to do it: the aliens in the book were (definitely) scary by their behaviour/abilities, yet they had to make them "look scary" in a way that connects to our visceral feelings, rather to the logical fear that a non-earth-like life form would bring. Speaking about the cast: I would still have preferred the Japanese setting of the book compared to the more western one in the movie, but at least one of the two main characters in the movie had a well-chosen person playing it. Overall, I'd give the book a 4/5 rating, and the movie (still) a 3/5. I enjoyed both, and the main plot idea is, if not new in SF, still appealing.

The simplest possible DNS-based service which I could write to explore Amazon's DNS offering has to be dynamic DNS, so I set one up.. The record skx.dhcp.io can be updated to point to your current IP by running:

curl http://dhcp.io/set/efa6961c-f3dd-11e3-955b-00163e0816a2

Or to a fixed IP:

curl http://dhcp.io/set/efa6961c-f3dd-11e3-955b-00163e0816a2/1.2.3.4

The code is modular and pretty nice, and the Amazon integration is simple. (Although I need to write code to allow users to sign-up. I'll do that if it seems useful, I suspect there are already enough free ddns providers out there - though I might be the first to support IPv6 when I commit my next chunk of work!)

The Debian package of WordPress version 3.9.1 was uploaded to the ftp master recently. While the update was pretty simple, the upload took a lot more doing. I m not sure why the Debian ftp-master server didn t like me, but it was so slow. Strangely, even dcut uploads were slow and they are only a few lines of text. Apologies for the delay too, I m not sure why I didn t notice the update from 3.9 to 3.9.1 but there you go. The other change is that the package uses the system CA certificates rather than the ones pre-shipped with wordpress. This is done so that if the administrator makes decisions on what certificates to trust, then the wordpress client http libraries will follow that decision.

This was another good week. This week I focused on cleaning up the merge implementation as well as learning about Debian packaging. As far as cleaning up the implementation, I got a few tests written to test the merge function. Additionally I rewrote the merge command code (the code responsible for the kdb merge command, it depends on the implementation of merge I wrote last week). Now the kdb merge command takes in a parent key for each keyset and creates a keyset containing all the keys under the parent key. It then invokes the KeysetMerge function I wrote on those keysets and saves the returned keyset to the key database. Most of the week I spent learning about Debian packaging. I was able to get some hand-on experience by creating a package for the augeas plugin for Elektra. I modified the control file to include the libaugeas0 dependency and adding in a description of the plugin. Also I created a new libelektra-augeas4.install file to install the share library to the correct location on the system. Then, I tried building the source using git-buildpackage but unfortunately it failed on packaging the plugin because the libelektra-augeas.so file was never built. It turned out that the augeas plugin had to be added to ElektraCache.cmake under plugins_dep (plugins with dependencies) so that the plugin would be built on make. So I fixed that and ran buildpackage again and voila! It worked! I successfully make my first Debian package! The other thing I looked into was how configuration files get updated during a package upgrade under Debian. It turns out, most package define their configurations as conffiles . These conffiles do not get overwritten during package upgrade if the user has edited them. Basically, during an upgrade, dpkg calculates a checksum on each conffile and if it has changed, prompts the user what to do. Instead, the goal of our project is to attempt an automatic merge of the conffile and if successful, used the merge version. If the merge is unsuccessful dpkg will prompt the user as usual. I need to figure out how to change dpkg s behavior during an upgrade with a conffile so I can build a prototype of a package upgrade merging a file. Lastly, this week I looked into adding tab completion to the kdb tool. Currently kdb does not try to complete commands using tab completion in bash. It turns out adding tab completion isn t that difficult. You basically just need to write rules for how tab completion should work for your program and add it to /etc/bash_completion.d/ I wrote a basic tab completion script for kdb that will complete the commands for kdb. It follows here: #Proof of concept bash completion for kdb. You must copy this file to /etc/bash_completion.d/kdb and load it with ". /etc/bash_completion.d/kdb"
_kdb()

local cur prev opts
COMPREPLY=()
cur="$ COMP_WORDS[COMP_CWORD] "
prev="$ COMP_WORDS[COMP_CWORD-1] "
opts="check convert cp export file fstab get getmeta import info ls lsmeta merge mount mv rm set setmeta sget shell test umount vset" if [[ $ cur == * ]] ; then
COMPREPLY=( $(compgen -W "$ opts " -- $ cur ) )
return 0
fi

complete -F _kdb kdb Its just a proof on concept but its a really neat feature and surprisingly easy to implement. One of the other students working on Elektra, Felix, is also working on tab completion. I think we will collaborate and have this feature implemented for kdb very soon. For next week I have a few goals I would like to accomplish. First of all I will have a working prototype of a package being upgraded with automatic conffile merging using kdb merge. Second, I want to continue working on the merge implementation to make it cleaner and work on more sophisticated keysets. I also need to add better error handling to tell if a merge was successful or not, and if not why. Third, I want to work on some of the lintan errors for the deb package of Elektra 0.8.6 and try to get some of those fixed to move closer toward release. Lastly I want to updated the kdb man page for Debian to make it more informative for the shell tool. I was able to get all my goals done for this week except the man page and getting some of the lintian errors fixed up. Overall though it was a very productive week. Until next week,
Ian S. Donnelly