Occasionally, one gets in touch with kind of foreign technologies and needs to get stuff working anyways. Recently, I had to do some various hacking with and around .bat files. Bat files are a kind of script files for Microsoft Windows. Calling external commands Imagine need to call some other command, let s say git diff. So from a cmd thing, you would write

git diff

similar to writing shell scripts on unixes. But there is a catch. If the thing you want to call is another bat-script, just calling it ensures it replaces the current script and never returns. So you need

call git diff

if the command you want to run is a bat file and you want to return to your script. Calling an external helper next to your script
If you for some reason needs to call some external helper placed next to your script, there is a helpful thing to do that as well. Imagine your helper is called helper.bat

call %~dp0helper.bat

is the very self-explanatory way of doing that. Stopping execution of your script If you somehow encounter some condition in your script that requires you to stop your script, there is a command exit handy. It even takes a argument for what error code there is.

exit 2

stops your script with return code 2. But it also have the nice added feature that if you do it in a script you run by hand in a terminal, it also exits the terminal. Luckily there is also a fix for that:

exit /b 2

and it doesn t exit your interactive terminal, and it sets the %ERRORLEVEL% variable to the exit code. Fortunately, the fun doesn t stop here. If the script is run non-interactively, exit /b doesn t set the exit code for for example perl s system() call. You need to use exit without /b for that. So now you need two scripts. one for interactive use that calls exit /b and a similar one using exit for use by other apps/scripts. Or, we can combine some of our knowledge and add a extra layer of indirection.

• write your script for interactive use (with exit /b) and let s call it script.bat
• create a simple wrapper script
  

  call %~dp0script.bat
  exit %ERRORLEVEL%

• call the wrapper for non-interactive use

and then success. Oh. and on a unrelated note. Windows can t schedule tasks for users that aren t logged in and don t have a password set. The response Access Denied is the only clue given.

Hi Everybody! Hope you have been enjoying my tutorial on writing plug-ins so far. In Part 1 we covered the basic overview of a plug-in. Part 2 covered a plug-in s contract and the best way to write one. Now, for Part 3 we are going to cover the meat of a plug-in, the actual coding. As you should know from reading Part 1, there are five main functions used for plug-ins, elektraPluginOpen, elektraPluginGet, elektraPluginSet, ELEKTRA_PLUGIN_EXPORT(Plugin), where Plugin should be replaced with the name of your plug-in. We are going to start this tutorial by focusing on the elektraPluginGet because it usually is the most critical function. As we discussed before, elektraPluginGet is the function responsible for turning information from a file into a usable KeySet. This function usually differs pretty greatly between each plug-in. This function should be of type int, it returns 0 on success or another number on an error. The function will take in a Key, usually called parentKey which contains a string containing the path to the file that is mounted. For instance, if you run the command kdb mount /etc/linetest system/linetest line then keyString(parentKey) should be equal to /etc/linetest . At this point, you generally want to open the file so you can begin saving it into keys. Here is the trickier part to explain. Basically, at this point you will want to iterate through the file and create keys and store string values inside of them according to what your plug-in is supposed to do. I will give a few examples of different plug-ins to better explain. My line plug-in was written to read files into a KeySet line by line using the newline character as a delimiter and naming the keys by their line number such as (#1, #2, .. #_22) for a file with 22 lines. So once I open the file given by parentKey, every time a I read a line I create a new key, let s call it new_key using dupKey(parentKey). Then I set new_keys s name to lineNN (where NN is the line number) using keyAddBaseName and store the string value of the line into the key using keySetString. Once the key is initialized, I append it to the KeySet that was passed into the elektraPluginGet function, let s call it returned for now, using ksAppendKey(return, new_key). Now the KeySet will contain new_key with the name lineNN properly saved where it should be according to the kdb mount command (in this case, system/linetest/lineNN), and a string value equal to the contents of that line in the file. MY plug-in repeats these steps as long as it hasn t reached end of file, thus saving the whole file into a KeySet line by line. The simpleini plug-in works similarly, but it parses for ini files instead of just line-by-line. At their most simple level, ini files are in the format of name=value with each pair taking one line. So for this plug-in, it makes a lot of sense to name each Key in the KeySet by the string to the left of the = sign and store the value into each key as a string. For instance, the name of the key would be name and keyGetString(name) would return value .
As you may have noticed, simpleini and line plug-ins work very similarly. However, they just parse the files differently. The simpleini plug-in parses the file in a way that is more natural to ini file (setting the key s name to the left side of the equals sign and the value to the right side of the equals sign.) The elektraPluginGet function is the heart of a storage plug-in, its what allows Elektra to store configurations in it s database. This function isn t just run when a file is first mounted, but whenever a file gets updated, this function is run to update the Elektra Key Database to match. We also gave a brief overview of elektraPluginSet function. This function is basically the opposite of elektraPluginGet. Where elektraPluginGet reads information from a file into the Elektra Key Database, elektraPluginSet writes information from the database back into the mounted file. First have a look at the signature of elektraLineSet: elektraLineSet(Plugin *handle ELEKTRA_UNUSED, KeySet *toWrite, Key *parentKey) Lets start with the most important parameters, the KeySet and the parentKey. The KeySet supplied is the KeySet that is going to be persisted in the file. In our case it would contain the Keys representing the lines. The parentKey is the topmost Key of the KeySet at serves several purposes. First, it contains the filename of the destination file as its value. Second, errors and warnings can be emitted via the parentKey. We will discuss error handling in more detail later. The Plugin handle can be used to persist state information in a threadsafe way with elektraPluginSetData. As our plugin is not stateful and therefore does not use the handle, it is marked as unused in order to supress compiler warnings. Basically the implementation of elektraLineSet can be described with the following pseudocode:

open the file
if (error)

ELEKTRA_SET_ERROR(74, parentKey, keyString(parentKey));

for each key

write the key value together with a newline

close the file
The fullblown code can be found at https://github.com/ElektraInitiative/libelektra/blob/master/src/plugins/line/line.c As you can see, all elektraLineSet does is open a file, take each Key from the KeySet (remember they are named #1, #2 #_22) in order, and write each key as it s own line in the file. Since we don t care about the name of the Key in this case (other than for order), we just write the value of keyString for each Key as a new line in the file. That s it. Now, each time the mounted KeySet is modified, elektraPluginSet will be called and the mounted file will be updated. We haven t discussed ELEKTRA_SET_ERROR yet. Because Elektra is a library, printing errors to stderr wouldn t be a good idea. Instead, errors and warnings can be appended to a key in the form of metadata. This is what ELEKTRA_SET_ERROR does. Because the parentKey always exists even if a critical error occurres, we append the error to the parentKey. The first parameter is an id specifying the general error that occurred. A listing of existing errors together with a short description and a categorization can be found at https://github.com/ElektraInitiative/libelektra/blob/master/src/liberror/specification. The third parameter can be used to provide additional information about the error. In our case we simply supply the filename of the file that caused the error. The kdb tools will interprete this error and print it in a pretty way. Notice that this can be used in any plugin function where the parentKey is available. The elektraPluginOpen and elektraPluginClose functions are not commonly used for storage plug-ins, but they can be useful and are worth reviewing. elektraPluginOpen function runs before elektraPluginGet and is useful to do initialization if necessary for the plug-in. On the other hand elektraPluginClose is run after other functions of the plug-in and can be useful for freeing up resources. The last function, one that is always needed in a plug-in, is ELEKTRA_PLUGIN_EXPORT. This functions is responsible for letting Elektra know that the plug-in exists and which methods it implements. The code from my line function is a good example and pretty self-explanatory:

Plugin *ELEKTRA_PLUGIN_EXPORT(line)

return elektraPluginExport("line",
ELEKTRA_PLUGIN_GET, &elektraLineGet,
ELEKTRA_PLUGIN_SET, &elektraLineSet,
ELEKTRA_PLUGIN_END);

There you have it! This is the last part of my tutorial on writing a storage plug-in for Elektra. Hopefully you now have a good understanding of how Elektra plug-ins work and you ll be able to add some great functionality into Elektra through development of new plug-ins. I hope you enjoyed this tutorial and if you have any questions just leave a comment! Happy coding!
Ian S. Donnelly

GNOME has, for some reason or another, always been the default desktop environment in Debian since the installer is able to install a full desktop environment by default. Release after release, Debian has been shipping different versions of GNOME, first based on the venerable 1.2/1.4 series, then moving to the time-based GNOME 2.x series, and finally to the newly designed 3.4 series for the last stable release, Debian 7 wheezy . During the final stages of wheezy s development, it was pointed out that the first install CD image would not longer hold all of the required packages to install a full GNOME desktop environment. There was lots of discussion surrounding this bug or fact, and there were two major reactions to it. The Debian GNOME team rebuilt some key packages so they would be compressed using xz instead of gzip, saving the few megabytes that were needed to squeeze everything in the first CD. In parallel, the tasksel maintainer decided switching to Xfce as default desktop was another obvious fix. This change, unannounced and two days before the freeze, was very contested and spurred the usual massive debian-devel threads. In the end, and after a few default desktop flip flops, it was agreed that GNOME would remain as the default for the already frozen wheezy release, and this issue would be revisited later on during jessie s development. And indeed, some months ago, Xfce was again reinstated as Debian s default desktop for jessie as announced:

Change default desktop to xfce.
This will be re-evaluated before jessie is frozen. The evaluation will
start around the point of DebConf (August 2014). If at that point gnome
looks like a better choice, it ll go back as the default.
Some criteria for that choice will include:
* Popcon numbers for gnome on jessie. If gnome installations continue to
  rise fast enough despite xfce being the default (compared with, say
  kde installations), then we ll know that users prefer gnome.
  Currently we have no data about how many users would choose gnome when
  it s not the default. Part of the reason for switching to xfce now
  is to get such data.
* The state of accessability support, particularly for the blind.
* How well the UI works for both new and existing users. Gnome 3
  seems to be adding back many gnome 2 features that existing users
  expect, as well as making some available via addons. If it feels
  comfortable to gnome 2 (and xfce) users, that would go a long way
  toward switching back to it as the default. Meanwhile, Gnome 3 is also
  breaking new ground in its interface; if the interface seems more
  welcoming to new users, or works better on mobile devices, etc, that
  would again point toward switching back.
* Whatever size constraints exist for CD or other images at the time.
--
Hello to all the tech journalists out there. This is pretty boring.
Why don t you write a story about monads instead?

Joey Hess in dfca406eb694e0ac00ea04b12fc912237e01c9b5.

Suffice to say that the Debian GNOME team participants have never been thrilled about how the whole issue is being handled, and we ve been wondering if we should be doing anything about it, or just move along and enjoy the smaller amount of bug reports against GNOME packages that this change would bring us, if it finally made it through to the final release. During our real life meet-ups in FOSDEM and the systemd+GNOME sprint in Antwerp, most members of the team did feel Debian would not be delivering a graphical environment with the polish we think our users deserve, and decided we at least should try to convince the rest of the Debian project and our users that Debian will be best suited by shipping GNOME 3.12 by default. Power users, of course, can and know how to get around this default and install KDE, Xfce, Cinnamon, MATE or whatever other choice they have. For the average user, though, we think we should be shipping GNOME by default, and tasksel should revert the above commit again. Some of our reasons are:

• Accessibility: GNOME continues to be the only free desktop environment that provides full accessibility coverage, right from login screen. While it s true GNOME 3.0 was lacking in many areas, and GNOME 3.4 (which we shipped in wheezy) was just barely acceptable thanks to some last minute GDM fixes, GNOME 3.12 should have ironed out all of the issues and our non-expert understanding is that a11y support is now on par with what GNOME 2.30 from squeeze offered.
• Downstream health: The number of active members in the team taking care of GNOME in Debian is around 5-10 persons, while it is 1-2 in the case of Xfce. Being the default desktop draws a lot of attention (and bug reports) that only a bigger team might have the resources to handle.
• Upstream health: While GNOME is still committed to its time-based release schedule and ships new versions every 6 months, Xfce upstream is, unfortunately, struggling a bit more to keep up with new plumbing technology. Only very recently it has regained support to suspend/hibernate via logind, or support for Bluez 5.x, for example.
• Community: GNOME is one of the biggest free software projects, and is lucky to have created an ecosystem of developers, documenters, translators and users that interact regularly in a live social community. Users and developers gather in hackfests and big, annual conferences like GUADEC, the Boston Summit, or GNOME.Asia. Only KDE has a comparable community, the rest of the free desktop projects don t have the userbase or humanpower to sustain communities like this.
• Localization: Localization is more extensive and complete in GNOME. Xfce has 18 languages above 95% of coverage, and 2 at 100% (excluding English). GNOME has 28 languages above 95%, 9 of them being complete (excluding English).
• Documentation: Documentation coverage is extensive in GNOME, with most of the core applications providing localized, up to date and complete manuals, available in an accessible format via the Help reader.
• Integration: The level of integration between components is very high in GNOME. For example, instant messaging, agenda and accessibility components are an integral part of the desktop. GNOME is closely integrated to NetworkManager, PulseAudio, udisks and upower so that the user has access to all the plumbing in a single place. GNOME also integrates easily with online accounts and services (ownCloud, Google, MS Exchange ).
• Hardware: GNOME 3.12 will be one of the few desktop environments to support HiDPI displays, now very common on some laptop models. Lack of support for HiDPI means non-technical users will get an unreadable desktop by default, and no hints on how to fix that.
• Security: GNOME is more secure. There are no processes launched with root permissions on the user s session. All everyday operations (package management, disk partitioning and formatting, date/time configuration ) are accomplished through PolicyKit wrappers.
• Privacy: One of the latest focuses of GNOME development is improving privacy, and work is being done to make it easy to run GNOME applications in isolated containers, integrate Tor seamlessly in the desktop experience, better disk encryption support and other features that should make GNOME a more secure desktop environment for end users.
• Popularity: One of the metrics discussed by the tasksel change proponents mentioned popcon numbers. 8 months after the desktop change, Xfce does not seem to have made a dent on install numbers. The Debian GNOME team doesn t feel popcon s data is any better than a random online poll though, as it s an opt-in service which the vast majority of users don t enable.
• systemd embracing: One of the reasons to switch to Xfce was that it didn t depend on systemd. But now that systemd is the default, that shouldn t be a problem. Also given ConsoleKit is deprecated and dead upstream, KDE and Xfce are switching or are planning to switch to systemd/logind.
• Adaptation: Debian forced a big desktop change with the wheezy release, switching from the traditional GNOME 2.x to the new GNOME Shell environment. Switching again would mean more adaptation for uses when they ve had two years to experience GNOME 3.4. Furthermore, GNOME 3.12 means two years of improvements and polishing to GNOME 3.4, which should help with some of the rough edges found in the GNOME release shipped with wheezy.
• Administration: GNOME is easy to administrate. All the default settings can be defined by administrators, and mandatory settings can be forced to users, which is required in some companies and administrations; Xfce cannot do that. The close integration with freedesktop components (systemd, NM, PulseAudio ) also gives access to specific and useful administration tools.

In short, we think defaulting to GNOME is the best option for the Debian release, and in contrast, shipping Xfce as the default desktop could mean delivering a desktop experience that has some incomplete or rough edges, and not on par with Debian quality standards for a stable release. We believe tasksel should again revert the change and be uploaded as soon as possible, in order to get people testing images with GNOME the sooner the better, with the freeze only two months away. We would also like that in the future, changes of this nature will not be announced in a git commit log, but widely discussed in debian-project and the other usual development/decision channels, like the change of init system happened recently. We will, whichever the final decision is, continue to package GNOME with great care to ensure our users get the best possible desktop experience Debian can offer.

As mentioned by Rapha l Hertzog, I have been spending some time on improving Britney2. Just the other day I submitted a second branch for review that I expect to merge early next week. I also got another set patches coming up soon. Currently, none of them are really user visible, so unless you are hosting your own version of Britney, these patches are probably not all that interesting to you. The highlights:

1. Reduce the need for backtracking by finding semantically equivalent packages.
2. Avoid needing to set up a backtrack point in some cases.
   • This has the side-effect of eliminating some O(e^n) runtime cases.
3. Optimise installability testing of packages affected by a hinted migration.
   • This has the side-effect of avoiding some O(e^n) runtime cases when the post-hint state does not trigger said behaviour.
   • There is a follow-up patch for this one coming in the third series to fix a possible bug for a corner-case (causing a valid hint to be incorrectly rejected when it removed an uninstallable package).
4. Reduce the number of affected packages to test when migrating items by using knowledge about semantically equivalent packages.
   • In some cases, Britney can now do free migrations when all binaries being updated replace semantically equivalent packages.
5. (Merge pending) Avoid many redundant calls to sort_actions() , which exhibits at least O(n^2) runtime in some cases.
   • For the dataset Rapha l submitted, this patch shaves off over 30 minutes runtime. In the particular case, each call to sort_actions takes 3+ minutes and it was called at least 10 times, where it was not needed.
   • That said, sort_actions have a vastly lower runtime in the runs for Debian (and presumably also Ubuntu, since no one complained from their side so far).

The results so far: After the first patch series was merged, the Kali dataset (from Rapha l) could be processed in only ~2 hours. With the second patch series merged, the dataset will drop by another 30-50 minutes (most of which are thanks to the change mentioned in highlight #5). The third patch series currently do not have any mention-worthy performance related changes. It will probably be limited to bug fixes and some refactoring. Reflections: The 3 first highlights only affects the new installability tester meaning that the Britney2 instances at Ubuntu and Tanglu should be mostly unaffected by the O(n^2) runtime. Although those cases will probably just fail with several AIEEE s. :) The 5th highlight should equally interesting to all Britney2 instances though. For me, the most interesting part is that we have never observed the O(n^2) behaviour in a daily sid -> testing run. The dataset from Rapha l was basically a stable -> testing/sid run, which is a case I do not think we have ever done before. Despite our current updates, there is still room for improvements on that particular use case. In particular, I was a bit disheartened at how poorly our auto hinter(s) performed on this dataset. Combined they only assisted with the migration of something like 28 items . For comparison, the main run migrated ~7100 items and 9220 items were unable to migrate. Furthermore, the Original auto hinter spend the better part of 15 minutes computing hints at least it results in 10 items migrating. Links to the patches:

• First series (already merged)
• Second series (pending, to be merged Monday, the 11th of August)
• Third series (under development. Warning: the branch will be rebased if/as needed)

After some downtime due to the identi.ca changes, the Debian Twitter accounts are now back.

• Debian Bug: Lists all bugs reported - High traffic
• Debian Upload: Reports all new upload - High traffic
• Debian New: Reports packages in the NEW queue
• Debian Remove: Reports packages removed from the archive

New Twitter feed ideas are welcome.

I don't really like any of the ticketing systems I've ever needed to use, whether they've been used as bug tracking systems, user support issue management systems, or something else. Some are not too bad. I currently rely most on debbugs and ikiwiki. debbugs is the Debian bug tracking system. See https://www.debian.org/Bugs/ for an entry point. It's mostly mail based, with a read-only web interface. You report a bug by sending an email to submission address, and (preferably) include a few magic "pseudo-headers" at the top of your message body ot identify the package and version. There's tools to make this easier, but mostly it's just about sending an e-mail. All replies are via e-mails as well. Effectively, each bug becomes is own little dedicated mailing list. This is important. A ticket, whether it is a bug report or a support request, is all about the discussion. "Hey I have this problem..." followed by "Have you tried..." and so forth. Anything that makes that discussion easier and faster to have is better. It is my very strong opinion, and long experience, that the best way to have such a discussion is over e-mail. A lot of modern ticketing systems are web based. They might have an e-mail mode, perhaps read-only, but that's mostly an afterthought. It's a thing bolted onto the side of the system because people like me whinge otherwise. I like e-mail for this for several reasons.

• E-mail is push, not pull. I don't need to go look at a web page to be notified that something's happened.
• E-mail requires no extra usernames and passwords to manage. I don't need to create a new account every time I encounter a new ticketing system instance.
• E-mail makes it very easy to respond. I can just reply to a message. I don't need to go to a web site, log in, and find a reply button.
• I already have archives of my e-mail, so referring to old messages (or finding them) is easy and quick. (Mutt, offlineimap, and notmuch is my particular set of choices. But I'm not locked to them, and you can use whatever you like, too.)
• E-mail is a very rich format. Discussions are inherently threaded, and various character sets, languages, attachments, and other such things just work.

For these reasons, I strongly prefer ticketing systems in which e-mails are the primary form of discussions, and e-mail is a first class citizen. I don't mind if there's other ways to participate in the discussion, but if I have to use something else than e-mail, I tend not to be happy. I use ikiwiki to provide a distributed, shared notebook on bugs. It's a bit cumbersome, and doesn't work well for discussions. I think we can improve on the way debbugs works, however. I've been thinking about ticketing systems for Obnam (my backup program), since it gaining enough users that it's getting hard to keep track of discussions with just an e-mail client. Here's what I want:

• Obnam users do not need to care about there being a ticketing system. They report a problem by e-mailing the support mailing list, and they keep the list in cc when conducting the discussion. This is very similar to debbugs, with the distinction that there's no ticket numbers that must be kept in the replies.
• The support staff (that's me, but hopefully others as well) have access to the ticketing system, which automatically sorts incoming messages into tickets. Tickets have sufficient metadata that it's possible to track which ones have been dealt with, or still need work, and perhaps other things. Each ticket contain a Maildir with all the e-mails belonging to that ticket.
• The ticketing system is distributed. I need to be able to work on tickets offline, and to synchronise instances between different computers. Just like git. It's not enough to have an offline mode (e.g., queuing e-mails on my laptop for sending to debbugs when I'm back online).
• There is a reasonably powerful search engine that can quickly find the relevant tickets, and messages, based on various criteria.

I will eventually have this. I'm not saying I'm working on this, since I don't have enough free time to do that, but there's a git repository, and some code, and it imports e-mails automatically now. Some day there may even be a web interface. (This has been a teaser.)

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

WordPress released today a security release 3.9.2 which they fix several security issues, including a denial of service issue around XML. The corresponding Debian package 3.9.2+dfsg-1 is currently being uploaded to the Debian ftp-master server as I write this and should be available on the mirrors soon. Unfortunately at the time of writing, there are no CVE identifiers to match these problems up with, but refer to the wordpress page for details about these bugs. Andrew Nacin from WordPress has kindly outlined what versions are susceptible and it looks like the Debian squeeze (3.6.1+dfsg-1~deb6u4) and wheezy (3.6.1+dfsg-1~deb7u3) are vulnerable to at least some of these bugs which means for me its patch reading and back-porting time

Related articles

• Post Status: WordPress and Drupal teams collaborate for simultaneous security releases (poststat.us)
• WordPress 3.9.2 Fixes Security Vulnerabilities, Users Strongly Encouraged To Update (wp-cron.com)

Hi Everybody! This is the second installment of my tutorial, How-To: Write a Plug-In. Previously, in Part 1, I went over the basic interface of an Elektra Storage Plug-In. For this installment, I will be focusing on one of the most important aspects of a plug-in, its contract. The contract describes how a plug-in may behave. The main part of the contract describes to Elektra how it will modify the KeySet returned. This is what allows Elektra to work with various types of plug-ins. This guide will focus on one type of plug-in: the storage plug-in. We already have a published specification for plug-ins on our repository but I will reiterate the details here. The first part of the contract you will need is the system/elektra/modules/plugin (where plugin represents the name of your plug-in). All this key does is let elektra know that your plug-in exists. The next key is system/elektra/modules/plugin/exports. This key lets Elektra know that your plug-in exports symbols to Elektra. Below this key you need to create keys for each function you want to export, in my line plug-in I implemented functions for get and set so I will create two keys as follows:
keyNew ("system/elektra/modules/line/exports/get",
KEY_FUNC, elektraLineGet, KEY_END),
keyNew ("system/elektra/modules/line/exports/set",
KEY_FUNC, elektraLineSet, KEY_END),
So far we have told Elektra that our plugin exists and will be exporting functions for getting and setting keys. The next set of keys are the system/elektra/Plugin/infos keys. These are pretty self-explanatory. The first three children of this key, author, license, and description are pretty self explanatory. The infos/provides key tells Elektra the type of plug-in that is being used, this will be storage for any storage plug-in (which is what this tutorial focuses on). To be precise, it tells Elektra which abstract functionality is provided. This allows other plugins to reference abstract functionality instead of declaring a hard dependency to one specific plugin. For example plugins could state that they want to be placed before any other plugin doing the abstract functionality conversion instead of referencing for example the keytometa plugin directly. The info/placements key tells Elektra which functions of the plug-in it should call. Since I implemented get and set in the line plug-in, I would set this key to getstorage setstorage . Next is infos/needs and infos/recommends, infos/needs should contain a list of plug-ins or providers that your plug-in needs to work (see the info/provides key above). Otherwise this key needs to be set to be blank . infos/recommends works exactly like needs except that a plug-in that needs another plug-in won t form a valid backend if the other plug-in doesn t exist but if it only recommends having the other plug-in, it will still work in the others absence. Since Elektra 0.8.7, the best practice for creating a plug-in involves storing the info keys at the very top of a file named REAMDE.md in the same directory as the plugin source. For instance, in my line plugin, the first few lines of README.md are as follows:
- infos = Information about LINE plugin is in keys below
- infos/author = Ian Donnelly <ian.s.donnelly@gmail.com>
- infos/licence = BSD
- infos/needs =
- infos/provides = storage
- infos/placements = getstorage setstorage
- infos/description = Very simple storage plug-in which stores each line from a file as a key The rest of the README.md file should contain an English description of the plug-in. You can include an introduction to the plug-in, its purpose, any shortcomings it may have, and examples of how to use it. This README.md file is standard for GitHub which will automatically be displayed when a user is browsing your plug-in s directory in the repo. It is written in Markdown. In order to generate the contract from this file you must edit the CMakeLists.txt file in your plug-in source directory to include the following lines:
generate_readme (plugin)
add_includes (elektra-full $ CMAKE_CURRENT_BINARY_DIR )
include_directories ($ CMAKE_CURRENT_BINARY_DIR )
where you substitute plugin with the name of you plugin. This will generate a file called readme_plugin.c (once again, substitute plugin), in your plugin s build directory when you run the make command. The best way to declare the contract is within it s own function, elektraPluginContract. This makes it easier to manage the contract and is much more readable. This is the contract declaration for my line plug-in:

static inline KeySet *elektraLineContract()

return ksNew (30,
keyNew ("system/elektra/modules/line",
KEY_VALUE, "line plugin waits for your orders", KEY_END),
keyNew ("system/elektra/modules/line/exports", KEY_END),
keyNew ("system/elektra/modules/line/exports/get",
KEY_FUNC, elektraLineGet, KEY_END),
keyNew ("system/elektra/modules/line/exports/set",
KEY_FUNC, elektraLineSet, KEY_END),
#include "readme_line.c"
keyNew ("system/elektra/modules/line/infos/version",
KEY_VALUE, PLUGINVERSION, KEY_END),
KS_END);

Next, you will need to make sure to actually set the contract. This is always done in the elektraPluginGet function since this is technically the only REQUIRED function in a plug-in. We just create a new KeySet, set it to our contract, and append it to the returned KeySet. You can see how this is done for line (note that this code is at the very beginning of elektraLineGet):

if (!strcmp (keyName(parentKey), "system/elektra/modules/line"))

KeySet *moduleConfig = elektraLineContract();
ksAppend(returned, moduleConfig);
ksDel(moduleConfig);
return 1;


Note that the plugin contract is nothing special, but just a KeySet interpreted by the resolver forming an Elektra backend. Elektra will request the keys below system/elektra/modules/plugin (where plugin is the pluginname) as soon as it wants to know something about that plugin. Notice also the line #include "readme_line.c". This line, pulls in the contents of readme_line.c in my plug-in s build directory, which due to the lines we added in CMakeLists.txt will contain the contract as defined at the top of README.md. Any changes to the keys in README.md will be reflected in the plug-in next time it is built. Part 2 of this tutorial focuses on the plug-in contract by explaining what each element does and explaining how to implement a contract. For more information about plug-ins and more detailed examples I highly suggest reading Markus Thesis for Elektra. Chapter 4, which starts on page 61 goes into much more detail on Plug-Ins and explains the various features of the contracts. Look for Part 3 soon!

Since some time, those crappy Fritz!Box devices do not support WDS anymore, but rather a proprietary solution created by AVM. Now what happens if you have devices in another room that need/want wired access (like TVs, Playstations) or if you want to extend the range of your network? Buying another Fritz!Box is not very cost efficient What I did was to buy a cheap TP-Link TL-WR841N (can be bought for 18 euros) and installed OpenWRT on it. Here s how I configured it to act as a WiFi bridge. Basic overview: You configure OpenWRT into station mode (that is, as a WiFi client) and use relayd to relay between the WiFi network and your local network. You also need igmpproxy to proxy multicast packages between those networks, other UPnP stuff won t work. I did this on the recent Barrier Braker RC2. It should work on older versions as well, but I cannot promise it (I did not get igmpproxy to work in Attitude Adjustment, but that was probably my fault). Note: I don t know if it works with IPv6, I only use IPv4. You might want to re-start (or start) services after the steps, or reboot the router afterwards. Configuring WiFi connection to the FRITZ!Box Add to: /etc/config/network

config interface 'wwan'
	option proto 'dhcp'

(you can use any other name you want instead of wwan, and a static IP. This will be your uplink to the Fritz!Box) Replace wifi-iface in: /etc/config/wireless:

config wifi-iface
	option device 'radio0'
	option mode 'sta'
	option ssid 'FRITZ!Box 7270'
	option encryption 'psk2'
	option key 'PASSWORD'
	option network 'wwan'

(adjust values as needed for your network) Setting up the pseudo-bridge First, add wwan to the list of networks in the lan zone in the firewall. Then add a forward rule for the lan network (not sure if needed). Afterwards, configure a new stabridge network and disable the built-in DHCP server. Diff for /etc/config/firewall

@@ -10,2 +10,3 @@ config zone
 	list network 'lan'
+	list network 'wwan'
 	option input 'ACCEPT'
@@ -28,2 +29,7 @@ config forwarding
 
+# Not sure if actually needed
+config forwarding
+	option src 'lan'
+	option dest 'lan'
+
 config rule

Add to /etc/config/network

config interface 'stabridge'
	option proto 'relay'
	option network 'lan wwan'
	option ipaddr '192.168.178.26'

(Replace 192.168.178.26 with the IP address your OpenWRT router was given by the Fritz!Box on wlan0) Also make sure to ignore dhcp on the lan interface, as the DHCP server of the FRITZ!Box will be used: Diff for /etc/config/dhcp

@@ -24,2 +24,3 @@ config dhcp 'lan'
        option ra 'server'
+       option ignore '1'

Proxying multicast packages For proxying multicast packages, we need to install igmpproxy and configure it: Add to: /etc/config/firewall

# Configuration for igmpproxy
config rule
	option src      lan
	option proto    igmp
	option target   ACCEPT
config rule
	option src      lan
	option proto    udp
	option dest     lan
	option target   ACCEPT

(OpenWRT wiki gives a different 2nd rule now, but this is the one I currently use) Replace /etc/config/igmpproxy with:

config igmpproxy
	option quickleave 1
config phyint
	option network wwan
	option direction upstream
	list altnet 192.168.178.0/24
config phyint
	option network lan
	option direction downstream
	list altnet 192.168.178.0/24

(Assuming Fritz!Box uses the 192.168.178.0/24 network) Don t forget to enable the igmpproxy script:

# /etc/init.d/igmpproxy enable

Optional: Repeat the WiFi signal If you want to repeat your WiFi signal, all you need to do is add a second wifi-iface to your /etc/config/wireless.

config wifi-iface
	option device 'radio0'
	option mode 'ap'
	option network 'lan'
	option encryption 'psk2+tkip+ccmp'
	option key 'PASSWORD'
	option ssid 'YourForwardingSSID'

Known Issues If I was connected via WiFi to the OpenWRT AP and switch to the FRITZ!Box AP, I cannot connect to the OpenWRT router for some time. The igmpproxy tool writes to the log about changing routes. Future Work I ll try to get the FRITZ!Box replaced by something that runs OpenWRT as well, and then use OpenWRT s WDS support for repeating; because the FRITZ!Box 7270v2 is largely crap loading a page in its web frontend takes 5 (idle) 20 seconds (1 download), and it s WiFi speed is limited to about 20 Mbit/s in WiFi-n mode (2.4 GHz (or 5 GHz, does not matter), 40 MHz channel). It seems the 7270 has a really slow CPU.
Filed under: OpenWRT

I've been told I don't blog about my projects often enough, so here's a feature update on my Chrome Extension that adds various improvements to the Strava.com fitness tracker. All the features are optional and can be individually enabled in the options panel.

I m installing new 4TB disks on an older Dell server, it s a PowerEdge T110 with a G6950 CPU so it s not really old, but it s a couple of generations behind the latest Dell servers. I tried to enable UEFI booting, but when I turned that option on the system locked up during the BIOS process (wouldn t boot from the CD or take keyboard input). So I had to make it boot with a BIOS compatible MBR and a GPT partition table. Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02 BIOS boot partition
2 4096 25169919 12.0 GiB FD00 Linux RAID
3 25169920 7814037134 3.6 TiB 8300 Linux filesystem After spending way to much time reading various web pages I discovered that the above partition table works. The 1MB partition is for GRUB code and needs to be enabled by a parted command such as the following: parted /dev/sda set 1 bios_grub on /dev/sda2 is a RAID-1 array used for the root filesystem. If I was installing a non-RAID system I d use the same partition table but with a type of 8300 instead of FD00. I have a RAID-1 array over sda2 and sdb2 for the root filesystem and sda3, sdb3, sdc3, sdd3, and sde3 are used for a RAID-Z array. I m reserving space for the root filesystem on all 5 disks because it seems like a good idea to use the same partition table and the 12G per disk that is unused on sdc, sdd, and sde isn t worth worrying about when dealing with 4TB disks.

Qemu 2.1 was just released a few days ago, and is now a available on Debian/unstable. Trying out an (virtual) arm64 machine is now just a few steps away for unstable users:

$ sudo apt-get install qemu-system-arm 
$ wget https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-arm64-disk1.img
$ wget https://cloud-images.ubuntu.com/trusty/current/unpacked/trusty-server-cloudimg-arm64-vmlinuz-generic
$ qemu-system-aarch64 -m 1024 -cpu cortex-a57 -nographic -machine virt -kernel trusty-server-cloudimg-arm64-vmlinuz-generic \ 
-append 'root=/dev/vda1 rw rootwait mem=1024M console=ttyAMA0,38400n8 init=/usr/lib/cloud-init/uncloud-init ds=nocloud ubuntu-pass=randomstring' \
-drive if=none,id=image,file=trusty-server-cloudimg-arm64-disk1.img \
-netdev user,id=user0 -device virtio-net-device,netdev=user0 -device virtio-blk-device,drive=image 
[    0.000000] Linux version 3.13.0-32-generic (buildd@beebe) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1) ) #57-Ubuntu SMP Tue Jul 15 03:52:14 UTC 2014 (Ubuntu 3.13.0-32.57-generic 3.13.11.4)
[    0.000000] CPU: AArch64 Processor [411fd070] revision 0
...
-snip-
...
ubuntu@ubuntu:~$ cat /proc/cpuinfo 
Processor       : AArch64 Processor rev 0 (aarch64)
processor       : 0
Features        : fp asimd evtstrm 
CPU implementer : 0x41
CPU architecture: AArch64
CPU variant     : 0x1
CPU part        : 0xd07
CPU revision    : 0

Hardware        : linux,dummy-virt
ubuntu@ubuntu:~$

The "init=/usr/lib/cloud-init/uncloud-init ds=nocloud ubuntu-pass=randomstring" is ubuntu cloud stuff that will set the ubuntu user password to "randomstring" - don't use "randomstring" literally there, if you are connected to internets... For more detailed writeup of using qemu-system-aarch64, check the excellent writeup from Alex Bennee.

The trail to Abram's Falls seems more trecherous as we get older, but the sights and magic of the place are unchanged in our first visit in years.

[Warning: quite a bit of pics in this post] [Edit: changed the post title, while I love the music, the actual lyrics of "Shake Rattle and Roll" made me facepalm. Ronnie Dawson's song is better :)] Last weekend I've been in Senigallia for the 15th edition of Summer Jamboree.
It was my first time there, and it was epic. Really.
If you are into roots music and early rock'n'roll and/or into vintage 40s and 50s clothes, go there.
You won't regret it! (You have time until August 10th, hurry up!) If you follow my identi.ca account (whooo! shameless plug!), you may know that I love music in general and Blues, Jazz and Rockabilly in particular.
If you read my blog, you may know that I make clothes - particularly reproductions of 50s and retro clothes.
So, it's not much of a surprise that going to the Summer Jamboree has been a mindblowing experience to me.
What surprised me it's that I've felt the very same wonder of my first Debconf: the amazing feeling that you are not alone, there are other people like you out there, who love the same things you love, who are silly about the same little details (yes, I equally despise historically innacurate pin up shoes and non free software), who dance - metaphorically and not - at your same beat.
Same wonder I felt when I first read some authors - Orwell and David Foster Wallace, just to mention a couple - or when I first delved in anarchist thinkers.
By nature I'm not much of a social person, and I tend to live and love alone. But that sense of being part of something, to find like-minded people always blows me away. I'm not much of a blog writer, so I won't probably be able to give you a good impression of the awesomness of it.
But hey, watch me trying. The Vintage Market I spent most of the morning travelling by train to reach Senigallia (and met the most beautiful French girl ever in the process, who sketched me in her notebook because, hey!, I was already in full Rockabilly gear).
The hotel was pretty close to the station, and to the part of the city where the festival was taking place, so I spent a couple of hours sleeping, then started the adventure.
The festival takes place mostly near the Rocca Roveresca, a beautiful fifteenth century castle, and on its gardens, but the all the other venues are in walking distance.
All around the Rocca there is a market with vintage clothes, records, shoes, retro jewelry. A special mention for two fantastic dressmakers: Laura of Bloody Edith Atelier from Rome and Debora of The Black Pinafore from Sarzana. I bought just a piece from each of them, but I was able to do that only with a huge amount of self restraint. Guitars! Tattoos! Yes, I may have spent a bit drooling on the Gibson Cherry Red, and I tried (without amp, though) that beautiful orange Gretsch Electromatic. And Greg Gregory of the Travel Ink Tattoo Studio from UK was there, with his shiny Airstream. I also spent a while among the records in the Bear Family Records booth. They are a Germany based independent record label specialised in reissues of country and 50s rock'n'roll. Couldn't resist, and I bought a beautiful Sun Records' tshirt. Just Rockin' and Rollin'. Aka: dance time After that, it was time to dance. I missed the dance camp of the afternoon, but the DJ sets were fantastic, all 40s and 50s stuff, and I fell in love with Lindy Hop and Boogie Woogie, and well, obviously, Jive. I could have spent hours watching the people dancing, and clumsily trying the most basic moves myself. People And the people, did I mention the people?
They were cosplaying the 40s and 50s so wonderfully I couldn't help but take some photos (and find a new fetish of mine: men in 40s clothes. Sexy as hell). For instance, Angelo Di Liberto, artistic director of the festival with the beautiful burlesque artist Grace Hall. Or the amazingly dressed German couple I met in via Carducci. And this couple too, was pretty cool. The Prettiest Smile award goes to these lovely ladies! Cars Who knows me, can tell that I don't love cars.
They stink, they are noisy, they are big.
But these ones where shiny and looked beautiful. Also, the black Cadillac had the terrible effect on me of putting "Santa Claus is Back in Town" in my head (or, more precisely, Elvis tomcatting his way through the song, singing "Got no sleigh with reindeer / No sack on my back / You're gonna see me comin' in a big black Cadillac"). Music! Sadly, I missed Stray Cat's Slim Jim Phantom but I was just in time for Ben E. King.
It was lovely: backed by the house band (The Good Fellas), he sang a lot of old Drifters hits, from On Broadway to Save the Last Dance for Me to - obviously - the great Stand By Me. Then a bit of hillbilly country, with Shorty Tom and the Longshots, a French combo consisting of a double bass, a rhythm guitar and a steel guitar. And, well, more dancing: the dj sets on the three stages went on until 3 am. Day 2 The next morning I took advantage of the early opening of Rocca Roveresca to visit it. The Rocca itself is beautiful and very well maintained, and hosts various exhibitions.
"Marilyn In White" shows the incredible photos taken by George Barris on the set of "The Seven Year Itch" as well as some taken in 1962. Beautiful, really, especially the series on the beach. But the ones moving me were the pics from "Buddy Holly, The Day The Music Dies": a collection of photos taken by Bill Francis during the (sadly brief) career of Buddy Holly from the very beginnings to his death. After that, it was time to come back to year 2014, but really I felt like I've walked for a while in another decade and planet. And the cool thing is that I could enjoy the great 40s and 50s music and dances (and clothes!) without the horrible stereotypes and cultural norms of the time period. A total win. :) So, ehm, that's it. I'm a bit sad to be back, and to cheer myself up I'm already planning to attend Wanda Jackson gig in Aarburg (CH) next month.
And take Lindy Hop and Boogie lessons, obviously.

Oh man, I'm such a geek... Being a single parent has required a considerable amount of self-discipline on my behalf. I find I do best in an environment with routine to make sure stuff gets done. One of the things I did to try and make sure stuff got done was to form positive habits. To help and make this a bit more "fun", I started using HabitRPG, an online role-playing game based on habits. I've only ever used it in a half-arsed manner, and as a result, I die a lot. Often I'll do my dailies, but then forget to mark them off. Sometimes I just fall off the habit wagon altogether. And die. One of my dailies is to scoop my cat's litterboxes. For whatever reason, I find this a tad onerous, and had found myself falling out of the habit of doing it on a daily basis. My cat deserves better than this, so I wanted to get back on the habit wagon, but make it a bit more "fun" as well. I love NFC, I've been a big NFC weenie for a long time. It's a solution looking for a problem. I have a huge collection of NFC tags, and I've finally found a problem I could use them with. I wanted to make it more frictionless to mark a task as completed in HabitRPG. I didn't want to have to take out my phone, unlock it, open the HabitRPG app and check off the daily task. I just wanted to wave my phone at an NFC tag. Here's how I did it. The inimitable Paul Fenwick, who first inspired me to use HabitRPG, has a way more complicated set up to achieve something similar. The Site Reliability Engineer in me wanted the least number of moving parts and third-parties to have to get from my phone to HabitRPG. After some hunting around, I found this wiki page on integrating Tasker with HabitRPG's API, so based on that breadcrumb, I got hacking. I'd not used Tasker before. I was already using AutomateIt to do some other, reasonably dumb automation on my phone, though. Tasker is a little bit obtuse, and it took me a couple of days of casual fiddling with it to wrap my head around it's usage model. The fact that it can run arbitrary JavaScript, and that NFC Tools integrates with it is where the real awesome lies. So based off the wiki, I crafted a couple of bits of JavaScript, one to mark daily tasks as complete on HabitRPG, and one to query HabitRPG to see if they have been marked as complete. For the former, it was trivial, using NFC Tools, to write an NFC tag that then runs the Tasker task to call the HabitRPG API to mark a daily task as complete. That goal was now complete. The equally satisfying part was also having Tasker do a time-based conditional nag based on the state of the daily task in HabitRPG. So now if it gets to 4:45pm and I haven't scooped the litterboxes, my phone literally tells me I'd better go do it. I've also done the same thing with putting the dishwasher on. I've stuck an NFC tag on the dishwashing powder bottle lid, and I get a conditional reminder before bed time. It used to be an unconditional reminder with AutomateIt, and it was dumb, because I rarely forget to put the dishwasher on. Now, I can use HabitRPG to keep state on it instead. The hunk of JavaScript to update HabitRPG is very simple:

function mark_completed()   
  var http = new XMLHttpRequest();
  http.open("POST", http_post_url, false);
  http.setRequestHeader("x-api-user", global('HabitrpgUserid'));
  http.setRequestHeader("x-api-key", global('HabitrpgApiToken'));
  http.send();
  return(http.responseText); 
 
try   
  var result = mark_completed(); 
  catch(e)   
  var error = e.message; 
 

All of the interesting stuff is defined in variables preceding the JavaScript in the task definition. Here's a screenshot of the Task in Tasker that tells a thousand words: Similarly, to query HabitRPG, I'm using:

function query_task()   
  var http = new XMLHttpRequest();
  http.open("GET",http_get_url,false);
  http.setRequestHeader("x-api-user", global('HabitrpgUserid'));
  http.setRequestHeader("x-api-key", global('HabitrpgApiToken'));
  http.send();
  var p = JSON.parse(http.responseText);
  return p['completed'];
 
try   
  var task_completed = query_task(); 
  catch(e)   
  var error = e.message; 
 

It's only slightly trickier because you have to parse the JSON blob that comes back. Again, a screenshot. Now maybe I'll stop dying so much in HabitRPG, my cat will have the clean toilet she deserves, and I'll stop getting reminded about putting the dishwasher on when I already have. Better living through automation, that's my motto.

I m using Replicant on my Samsung SIII (i9300) phone (see my earlier posts). During my vacation the Replicant project released version 4.2-0002 as a minor update to their initial 4.2 release. I didn t anticipate any significant differences, so I followed the installation instructions but instead of wipe data/factory reset I chose wipe cache partition and rebooted. Everything appeared to work fine, but I soon discovered that NFC was not working. Using adb logcat I could get some error messages:

E/NFC-HCI ( 7022): HCI Timeout - Exception raised - Force restart of NFC service
F/libc    ( 7022): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 7046 (message)
I/DEBUG   ( 1900): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   ( 1900): Build fingerprint: 'samsung/m0xx/m0:4.1.1/JRO03C/I9300XXDLIB:user/release-keys'
I/DEBUG   ( 1900): Revision: '12'
I/DEBUG   ( 1900): pid: 7022, tid: 7046, name: message  >>> com.android.nfc <<<

The phone would loop trying to start NFC and having the NFC sub-system die over and over. Talking on #replicant channel, paulk quickly realized and fixed the bug. I had to rebuild the images to get things to work, so I took the time to create a new virtual machine based on Debian 7.5 for building Replicant on. As a side note, the only thing not covered by Replicant build dependency documentation was that I needed the Debian xmllint package to avoid a build failure and the Debian xsltproc package to avoid a error message being printed in the beginning of every build. Soon I had my own fresh images and installed them and NFC was working again, after installing the non-free libpn544_fw.so file. During this, I noticed that there are multiple libpn544_fw.so files floating around. I have the following files:

version string	source
libpn544_fw_C3_1_26_SP.so	internet
libpn544_fw_C3_1_34_SP.so	stock ROM on S3 bought in Sweden during 2013 and 2014 (two phones)
libpn544_fw_C3_1_39_SP.so	internet

(For reference the md5sum's of these files are 682e50666effa919d557688c276edc48, b9364ba59de1947d4588f588229bae20 and 18b4e634d357849edbe139b04c939593 respectively.) If you do not have any of these files available as /vendor/firmware/libpn544_fw.so you will get the following error message:

I/NfcService( 2488): Enabling NFC
D/NFCJNI  ( 2488): Start Initialization
E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
E/NFCJNI  ( 2488): phLibNfc_Mgt_Initialize() returned 0x00ff[NFCSTATUS_FAILED]
E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFCJNI  ( 2488): Firmware update FAILED
E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFCJNI  ( 2488): Firmware update FAILED
E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFCJNI  ( 2488): Firmware update FAILED
E/NFCJNI  ( 2488): Unable to update firmware, giving up
D/NFCJNI  ( 2488): phLibNfc_Mgt_UnConfigureDriver() returned 0x0000[NFCSTATUS_SUCCESS]
D/NFCJNI  ( 2488): Terminating client thread...
W/NfcService( 2488): Error enabling NFC

Using the first (26) file or the last (39) file does not appear to be working on my phone, I get the following error messages. Note that the line starting with 'NFC capabilities' has 'Rev = 34' in it, possibly indicating that I need the version 34 file.

I/NfcService( 5735): Enabling NFC
D/NFCJNI  ( 5735): Start Initialization
D/NFCJNI  ( 5735): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 8
D/NFCJNI  ( 5735): Download new Firmware
W/NFCJNI  ( 5735): Firmware update FAILED
D/NFCJNI  ( 5735): Download new Firmware
W/NFCJNI  ( 5735): Firmware update FAILED
D/NFCJNI  ( 5735): Download new Firmware
W/NFCJNI  ( 5735): Firmware update FAILED
E/NFCJNI  ( 5735): Unable to update firmware, giving up
D/NFCJNI  ( 5735): phLibNfc_Mgt_UnConfigureDriver() returned 0x0000[NFCSTATUS_SUCCESS]
D/NFCJNI  ( 5735): Terminating client thread...
W/NfcService( 5735): Error enabling NFC

Loading the 34 works fine.

I/NfcService( 2501): Enabling NFC
D/NFCJNI  ( 2501): Start Initialization
D/NFCJNI  ( 2501): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0
D/NFCJNI  ( 2501): phLibNfc_SE_GetSecureElementList()
D/NFCJNI  ( 2501): 
D/NFCJNI  ( 2501): > Number of Secure Element(s) : 1
D/NFCJNI  ( 2501): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI  ( 2501): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI  ( 2501): NFC Initialized
D/NdefPushServer( 2501): start, thread = null
D/NdefPushServer( 2501): starting new server thread
D/NdefPushServer( 2501): about create LLCP service socket
D/NdefPushServer( 2501): created LLCP service socket
D/NdefPushServer( 2501): about to accept
D/NfcService( 2501): NFC-EE OFF
D/NfcService( 2501): NFC-C ON

What is interesting is, that my other S3 running CyanogenMod does not have the libpn544_fw.so file but still NFC works. The messages are:

I/NfcService( 2619): Enabling NFC
D/NFCJNI  ( 2619): Start Initialization
E/NFC-HCI ( 2619): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFC     ( 2619): Firmware image not available: this device might be running old NFC firmware!
D/NFCJNI  ( 2619): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0
D/NFCJNI  ( 2619): phLibNfc_SE_GetSecureElementList()
D/NFCJNI  ( 2619): 
D/NFCJNI  ( 2619): > Number of Secure Element(s) : 1
D/NFCJNI  ( 2619): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI  ( 2619): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI  ( 2619): NFC Initialized
D/NdefPushServer( 2619): start, thread = null
D/NdefPushServer( 2619): starting new server thread
D/NdefPushServer( 2619): about create LLCP service socket
D/NdefPushServer( 2619): created LLCP service socket
D/NdefPushServer( 2619): about to accept
D/NfcService( 2619): NFC-EE OFF
D/NfcService( 2619): NFC-C ON

Diffing the two NFC-relevant repositories between Replicant (external_libnfc-nxp and packages_apps_nfc) and CyanogenMod (android_external_libnfc-nxp and android_packages_apps_Nfc) I found a commit in Replicant that changes a soft-fail on missing firmware to a hard-fail. I manually reverted that patch in my build tree, and rebuilt and booted a new image. Enabling NFC now prints this on my Replicant phone:

I/NfcService( 2508): Enabling NFC
D/NFCJNI  ( 2508): Start Initialization
E/NFC-HCI ( 2508): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFC     ( 2508): Firmware image not available: this device might be running old NFC firmware!
D/NFCJNI  ( 2508): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0
D/NFCJNI  ( 2508): phLibNfc_SE_GetSecureElementList()
D/NFCJNI  ( 2508): 
D/NFCJNI  ( 2508): > Number of Secure Element(s) : 1
D/NFCJNI  ( 2508): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI  ( 2508): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI  ( 2508): NFC Initialized
D/NdefPushServer( 2508): start, thread = null
D/NdefPushServer( 2508): starting new server thread
D/NdefPushServer( 2508): about create LLCP service socket
D/NdefPushServer( 2508): created LLCP service socket
D/NdefPushServer( 2508): about to accept
D/NfcService( 2508): NFC-EE OFF
D/NfcService( 2508): NFC-C ON

And NFC works! At least YubiKey NEO with the Yubico Authenticator app. One less non-free blob on my phone. I have double-checked that power-cycling the phone (even removing battery for a while) does not affect anything, so it seems the NFC chip has firmware loaded from the factory. Question remains why that commit was added. Is it necessary on some other phone? I have no idea, other than if the patch is reverted, S3 owners will have NFC working with Replicant without non-free software added. Alternatively, make the patch apply only on the platform where it was needed, or even to all non-S3 builds.

In the past I used to pay for an email->SMS gateway, which was used to alert me about some urgent things. That was nice because it was bi-directional, and at one point I could restart particular services via sending SMS messages. These days I get it for free, and for my own reference here is how you get to receive free SMS alerts via Orange, which is my mobile phone company. If you don't use Orange/EE this will probably not help you. The first step is to register an Orange email-account, which can be done here:

• http://web.orange.co.uk/p/communicate/home

Once you've done that you'll have an email address of the form example@orange.net, which is kinda-sorta linked to your mobile number. You'll sign in and be shown something that looks like webmail from the early 90s. The thing that makes this interesting is that you can look in the left-hand menu and see a link called "SMS Alerts". Visit it. That will let you do things like set the number of SMSs you wish to receive a month (I chose "1000"), and the hours during which delivery will be made (I chose "All the time"). Anyway if you go through this dance you'll end up with an email address example@orange.net, and when an email arrives at that destination an SMS will be sent to your phone. The content of the SMS will be the subject of the mail, truncated if necessary, so you can send a hello message to yourself like this:

echo "nop"   mail -s "Hello, urgent message is present" username@orange.net

Delivery seems pretty reliable, and I've scheduled the mailbox to be purged every week, to avoid it getting full:

Hostname	pop.orange.net
Username	Your mobile number
Password	Your password

If you wished to send mail from this you can use smtp.orange.net, but I pity the fool who used their mobile phone company for their primary email address.

A new release of our BH package providing Boost headers for use by R is now on the CRAN mirrors. This release is the third based on Boost 1.54.0. At the request of the maintainer of the recent added RcppMLPACK package, it adds the Boost.Heap library. Boost.Heap implements priority queues which extend beyond the corresponding (and somewhat simpler) class in the STL. Key features of the Boost.Heap priority queues are mutability, iterators, ability to merge, stable sort, and comparison. No other changes were made.

Changes in version 1.54.0-3 (2014-08-03)

• Added Boost Heap library which will be needed by the next version of RcppMLPACK

Courtesy of CRANberries, there is also a diffstat report for the most recent release. Comments and suggestions are welcome via the mailing list or issue tracker at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.