The tint package, whose name stands for Tint Is Not Tufte , on CRAN offers a fresh take on the excellent Tufte-style for html and pdf presentations. It marks a milestone for me: I finally have a repository with more "stars" than commits. Gotta keep an eye on the big prize... Kidding aside, and as a little teaser, here is what the pdf variant looks like: This release corrects one minor misfeature in the pdf variant. It also adds some spit and polish throughout, including a new NEWS.Rd file. We quote from it the entries for the current as well as previous releases:

Changes in tint version 0.0.3 (2016-10-15)

• Correct pdf mode to no use italics in table of contents (#9 fixing #8); also added color support for links etc
• Added (basic) Travis CI support (#10)

Changes in tint version 0.0.2 (2016-10-06)

• In html mode, correct use of italics and bold
• Html function renamed to tintHtml Roboto fonts with (string) formats and locales; this allow for adding formats; (PRs #6 and #7)
• Added pdf mode with new function tintPdf(); added appropriate resources (PR #5)
• Updated resource files

Changes in tint version 0.0.1 (2016-09-24)

• Initial (non-CRAN) release to ghrr drat

Courtesy of CRANberries, there is a comparison to the previous release. More information is on the tint page. For questions or comments use the issue tracker off 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.

While looking at the action needed -paragraph of one of my packages, I saw that a dependency was orphaned and needed a new maintainer. So I decided to restart DOPOM (Debian Orphaned Package Of the Month), that I started in 2012 with ent as the first package. This month I adopted libmatthew-java. Sure it was not a big deal as the QA-team already did a good job and kept the package in shape. But now there is one burden lifted from their shoulders. According to the Work-Needing and Prospective Packages page 956 packages are ophaned at the moment. If every Debian contributor grabs one of them, we could unwind the QA-team (no, just kidding). So similar to NEW which was down to 0 this year, can we get rid of the WNPP as well? At least for a short time?

anytime arrived on CRAN with releases 0.0.1 and 0.0.2 about a month ago. anytime aims to convert anything in integer, numeric, character, factor, ordered, ... format to POSIXct (or Date) objects. Release 0.0.3 brings a bugfix for Windows (where for dates before the epoch of 1970-01-01, accessing the tm_isdst field for daylight savings would crash the session) and a small (unexported) extension to test format strings. This last feature plays well the ability to add format strings which we added in 0.0.2. The NEWS file summarises the release:

Changes in Rcpp version 0.0.3 (2016-10-13)

• Added (non-exported) helper function testFormat()
• Do not access tm_isdst on Windows for dates before the epoch (pull request #13 fixing issue #12); added test as well

Courtesy of CRANberries, there is a comparison to the previous release. More information is on the anytime page. For questions or comments use the issue tracker off 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.

Hosted Weblate provides also free hosting for free software projects. I'm quite slow in processing the hosting requests, but when I do that, I process them in a batch and add several projects at once. This time, the newly hosted projects include:

• JaMuz - Music management tool
• World-Weather - An Android app that uses the Open Weather Map API
• GNUSim8085 - A graphical simulator, assembler and debugger for the Intel 8085 microprocesso
• Commons Mobile App - Upload pictures from Android to Wikimedia Commons
• Debian Edu Documentation
• Duplicati - Store securely encrypted backups on cloud storage services

Filed under: Debian English SUSE Weblate 0 comments

Hosted Weblate provides also free hosting for free software projects. I'm quite slow in processing the hosting requests, but when I do that, I process them in a batch and add several projects at once. This time, the newly hosted projects include:

• JaMuz - Music management tool
• World-Weather - An Android app that uses the Open Weather Map API
• GNUSim8085 - A graphical simulator, assembler and debugger for the Intel 8085 microprocesso
• Commons Mobile App - Upload pictures from Android to Wikimedia Commons
• Debian Edu Documentation
• Duplicati - Store securely encrypted backups on cloud storage services

Filed under: Debian English SUSE Weblate 0 comments

Introduction NX is a software suite which implements very efficient compression of the X11 protocol. This increases performance when using X applications over a network, especially a slow one. NX (v3) has been originally developed by NoMachine and has been Free Software ever since. Since NoMachine obsoleted NX (v3) some time back in 2013/2014, the maintenance has been continued by a versatile group of developers. The work on NX (v3) is being continued under the project name "nx-libs". Release Announcement On Thursday, Oct 13th, version 3.5.99.2 of nx-libs has been released [1]. This release brings a major backport of libNX_X11 to the status of libX11 1.3.4 (as provided by X.org). On top of that, all CVE fixes provided for libX11 by the Debian X11 Strike Force and the Debian LTS team got cherry-picked to libNX_X11, too. This big chunk of work has been performed by Ulrich Sibiller and there is more to come. We currently have a pull request pending review that backports more commits from libX11 (bumping the status of libNX_X11 to the state of libX11 1.6.4, which is the current HEAD on the X.org Git site). Another big clean-up performed by Ulrich is the split-up of XKB code which got symlinked between libNX_X11 and nx-X11/programs/Xserver. This brings in some code duplications but allows maintaing the nxagent Xserver code and the libNX_X11 code separately. In the upstream ChangeLog you will find some more items around code clean-ups and .deb packaging, see the diff [2] on the ChangeLog file for details. So for this releas, a very special and massive thanks goes to Ulrich Sibiller!!! Well done!!! Change Log A list of recent changes (since 3.5.99.1) can be obtained from here. Known Issues This version of nx-libs is known to segfault when LDFLAGS / CFLAGS have the -pie / -fPIE hardening flags set. This issue is currently under investigation. Binary Builds You can obtain binary builds of nx-libs for Debian (jessie, stretch, unstable) and Ubuntu (trusty, xenial) via these apt-URLs:

• Debian: deb http://packages.arctica-project.org/ubuntu jessie,stretch,sid main
• Ubuntu: deb http://packages.arctica-project.org/ubuntu trusty,xenial main

Our package server's archive key is: 0x98DE3101 (fingerprint: 7A49 CD37 EBAE 2501 B9B4 F7EA A868 0F55 98DE 3101). Use this command to make APT trust our package server:

 wget -qO - http://packages.arctica-project.org/archive.key   sudo apt-key add -

The nx-libs software project brings to you the binary packages nxproxy (client-side component) and nxagent (nx-X11 server, server-side component). Ubuntu developers, please note: we have added nightly builds for Ubuntu latest to our build server. This has been Ubuntu 16.10 so far, but we will soon drop 16.10 support in nightly builds and add 17.04 support. References

• [1] https://github.com/ArcticaProject/nx-libs/releases/tag/3.5.99.2
• [2] https://github.com/ArcticaProject/nx-libs/commit/29e29342ee73fcd52d3b67b...

Bug reporting is an art form that is too often neglected in software projects. Bug reports allow contributors to participate without deep technical knowledge and at the same time provide a crucial space for developers to be made aware of issues with their software that they could not have foreseen or found themselves, for lack of resources, variety or imagination.

Prior art Unfortunately, there are rarely good guidelines for submitting bug reports. Historically, people have pointed towards How to report bugs effectively or How to ask questions the smart way. While those guides can be useful for motivated people and may seem attractive references for project managers, they suffer from serious issues:

• they are written by technical people, for non-technical people
• as a result, they have a deeply condescending attitude such as calling people "stupid" or various animal names like "mongoose"
• they are also very technical themselves: one starts with a copyright notice and a changelog, the other uses magic words like "Core dumps" and $Id$
• they are too long: sgtatham's is about 3600 words long, esr's is even longer at about 11800 words. those texts will take about 20 to 60 minutes to read by an average reader, according to research

Individual projects have their own guides as well. Linux has the REPORTING_BUGS file that is a much shorter 1200 that can be read under 5 minutes, provided that you can understand the topic at hand. Interestingly, that guide refers to both esr's and sgtatham's guidelines, which means, in the degenerate case where the user hasn't had the "privilege" of reading esr's prose already, they will have an extra hour and a half of reading to do to have honestly followed the guidelines before reporting the bug. I often find good documentation in the Tails project. Their bug reporting guidelines are easily accessible and quick to read, although they still might be too technical. It could be argued that you need to get technical at some point to get that information out, of course. In the Monkeysign project, I have started a bug reporting guide that doesn't yet address all those issues. I am considering writing a new guide, but I figured I would look at other people's work and get feedback before writing my own standard.

What's the point? Why have those documents been written? Are people really expected to read them before seeking help? It seems to me unlikely that someone would:

1. be motivated enough to do something about a broken part of their computer
2. figure out they can do something about it
3. read a fifteen thousand words novel about how to report a bug...
4. just to finally write a 20-line bug report that has no warranty of support attached to it

And if I would be a paying customer, I wouldn't want to be forced to waste my time reading that prose either: it's your job to help me fix your broken things, not the reverse. As someone doing consulting these days: I totally understand: it's not you, the user, it's us, the developers, that have a problem. We have been socialized through computers, and it makes us weird and obtuse, but that's no excuse, and we need to clean up our act. Furthermore, it's surprising how often we get (and make!) bug reports that can be difficult to use. The Monkeysign project is very "technical" and I have expected that the bug reports I would get would be well written, with ways to reproduce and so on, but it happened that I received bug reports that were all over the place, didn't have any ways of reproducing or were simply incomplete. Those three bug reports were filed by people that I know to be very technically capable: one is a fellow Debian developer, the second had filed a good bug report 5 days before, and the third one is a contributor that sent good patches before. In all three cases, they knew what they were doing. Those three people probably read the guidelines mentioned in the past. They may have even read the Monkeysign bug reporting guidelines as well. I can only explain those bug reports by the lack of time: people thought the issue was obvious, that it would get fixed rapidly because, obviously, something is broken. We need a better way.

The takeaway What are those guides trying to tell us?

1. ask questions in the right place
2. search for similar questions and issues before reporting the bug
3. try to make the developers reproduce the issues
4. failing that, try to describe the issue as well as you can
5. write clearly, be specific and verbose yet concise

There are obviously contradictions in there, like sgtatham telling us to be verbose and esr tells us to, basically, not be verbose. There is definitely a tension in there, and there are many, many more details about how great bug reports can be if done properly. I tend towards the side of terseness in our descriptions: people that will know how to be concise will be, people that don't will most likely not learn by reading a 12 000 words novel that, in itself, didn't manage to be parsimonious. But I am willing to allow for verbosity in bug reports: I prefer too many details instead of missing a key bit of information.

Issue trackers Step 1 is our job: we should send people in the right place, and give them the right tools. Monkeysign used to manage bugs with bugs-everywhere and this turned out to be a terrible idea: you had to understand git and bugs-everywhere to file any bug reports. As a result, there were exactly zero bug reports filed by non-developers during the whole time BE was used, although some bugs were filed in the Debian Bugtracker. So have a good bug tracker. A mailing list or email address is not a good bug tracker: you lose track of old issues, and it's hard for newcomers to search the archives. It does have the advantage of having a unified interface for the support forum and bug tracking, however. Redmine, Gitlab, Github and others are all decent-enough bug trackers. The key point is that the issue tracker should be publicly available, and users should be able to register easily to file new issues. You should also be able to mass-edit tickets and users should be able to discover the tracker's features easily. I am sorry to say that the Debian BTS somewhat falls short on those two features. Step 2 is a shared responsibility: there should be an easy way to search for issues, and we should help the user looking for similar issues. Stackexchange sites do an excellent job at this, by automatically searching for similar questions while you write your question, suggesting similar ones in an attempt to weed out duplicates. Duplicates still happen, but they can then clearly be marked and linked with a distinct mechanism. Most bug trackers do not offer such high level functionality, but should, so I feel the fault lies more on "our" end than at the user's end.

Reproducing the environment Step 3 and 4 are more or less the user's responsibility. We can detail in our documentation how to clearly share the environment where we reproduced the bug, for example, but in the end, the user decides if they want to share that information or not. In Monkeysign, I have finally implemented joeyh's suggestion of shipping the test suite with the program. I can now tell people to run the test suite in their environment to see if this is a regression that is specific to their environment - so a known bug, in a way - or a novel bug for which I can look at writing a new unit test. I also include way more information about the environment in the --version output, an idea I brought forward in the borg project to ease debugging. That way, people can just send the output of monkeysign --test and monkeysign --version, and I have a very good overview of what is happening on their end. Of course, Monkeysign also supports the usual --verbose and --debug flag that users should enable when reproducing issues. Another idea is to report bugs directly from the application. We have all seen Firefox or other software have automatic bug reporting tools, but somehow those seem unsatisfactory for a user: we have no feedback of where the report goes, if it's followed up on. It is useful for larger project to get statistical data, but not so useful for users in the short term. Monkeysign tries to handle exceptions in the code in a graceful way, but could do better. We use a small library to handle exceptions, but that library has since then been improved to directly file bugs against the Github project. This assumes the user is logged into Github, but it is nice to pre-populate bug reports with the relevant information up front.

Issue templates In the meantime, to make sure people provide enough information, I have now moved a lot of the bug reporting guidelines to a separate issue template. That issue template is available through the issue creation form now, although it is not enabled by default, a weird limitation of Gitlab. Issue templates are available in Gitlab and Github. Issue templates somewhat force users in a straight jacket: there is already something to structure their bug report. Those could be distinct form elements that had to be filled in, but I like the flexibility of the template, and the possibility for users to just escape the formalism and just plead for help in their own way.

Issue guidelines In the end, I opted for a short few paragraphs in the style of the Tails documentation, including a reference to sgtatham, as an optional future reference:

• Before you report a new bug, review the existing issues in the online issue tracker and the Debian BTS for Monkeysign to make sure the bug has not already been reported elsewhere.
• The first aim of a bug report is to tell the developers exactly how to reproduce the failure, so try to reproduce the issue yourself and describe how you did that.
• If that is not possible, try to describe what went wrong in detail. Write down the error messages, especially if they have numbers.
• Take the necessary time to write clearly and precisely. Say what you mean, and make sure it cannot be misinterpreted.
• Include the output of monkeysign --test, monkeysign --version and monkeysign --debug in your bug reports. See the issue template for more details about what to include in bug reports.

If you wish to read more about issues regarding communication in bug reports, you can read How to Report Bugs Effectively, which takes around 20 to 30 minutes.

Unfortunately, short of rewriting sgtatham's guide, I do not feel there is much more we can do as a general guide. I find esr's guide to be too verbose and commanding, so sgtatham it will be for now.

The prose and literacy In the end, there is a fundamental issue with reporting bugs: it assumes our users are literate and capable of writing amazing prose that we will enjoy reading as the last J.K. Rowling novel (if you're into that kind of thing). It's just an unreasonable expectation: some of your users don't even speak the same language as you, let alone read or write it. This makes for challenging collaboration, to say the least. This is where automated reporting makes sense: it doesn't require user's intervention, and the communication is mediated by machines without human intervention and their pesky culture. But we should, as maintainers, "be liberal in what we accept and conservative in what we send". Be tolerant, and help your users in fixing their issues. It's what you are there for, after all. And in the end, we all fail the same way. In an attempt to improve the situation on bug reporting guides, I seem to have myself written a 2000 short story that will have taken up a hopefully pleasant 10 minutes of your time at minimum. Hopefully I will have succeeded at being clear, specific, verbose and concise all at once and look forward to your feedback on how to improve our bug reporting culture.

For the last four years or so, I've had my Hi-Fi and the vast majority of my vinyl collection stored in a self-contained, mildly-customized Ikea unit. Since moving house this has been in my dining room which we have always referred to as the "play room", since we have a second dining room in which we actually dine. The intention for the play room was for it to be the room within which all our future children would have their toys kept, in an attempt to keep the living room from being overrun with plastic. The time has thus come for my Hi-Fi to come out of there, so we've moved it to our living room. Unfortunately, there's not enough room in the living room for the Ikea unit: I need something narrower for the space available. In the spirit of my original hack, I started looking at what others might have achieved with Ikea components. There are some great examples of open-style units built out of the (extremely cheap) Lack coffee tables, such as this ikeahackers article, but I'd prefer something more enclosed. One problem I've had with the Expedit unit was my cat trying to scratch the records. I ended up putting framed records at the front to cover the spines of the records within. If I were keeping the unit, I'd look at fitting hinges (another ikeahackers article) Asides from hacked Ikea stuff, there are a few companies offering traditional enclosed Hi Fi cabinets. I'm going to struggle to fit both the equipment and a subset of records into these, so I might have to look at storing them separately. In some ways that makes life easier: the records could go into a 1x4 Ikea KALLAX unit, leaving the amp and deck to home somewhere. Perhaps I could look at a bigger unit for under the TV. My parents have a nice Hi-Fi unit that pretends to be a chest of drawers. I'm fairly sure my Dad custom-built it, as it has a hinged top to provide access to the turntable and I haven't seen anything like that on the market. That brings me onto thinking about other AV things I'd like to achieve in the living room. I've always been interested in exploring surround sound, but my initial attempt in my prior flat did not go well, either because the room was not terribly suited accoustically, or because the Pioneer unit I bought was rubbish, or both. It seems that there aren't really AV receivers which are designed to satisfy both people wanting to use them in a Hi-Fi and a home cinema setting. I could stick to stereo and run the TV into my existing (or a new) amplifier, subject to some logistics around wiring. A previous house owner ran some phono cables under the hard-wood flooring from the TV alcove to the opposite side of the fire place, which might give me some options. There's also the world of wireless audio, Sonos etcetera. Realistically the majority of my music is digital nowadays, and it would be good to be able to listen to it conveniently in the house. I've heard good reports on the entry level Sonos stuff, but they seem to be Mono, and even the more high-end ones with lots of drivers have very small separation. I did buy a Chromecast Audio on a whim recently, but I haven't looked at it much yet: perhaps that's part of the solution. So, lots of stuff in the melting pot to figure out here!

Continuing on from the previous article, here is a (probably incomplete) list of the critical changes to Gitano which have been, or will be, worked on during the run toward a 1.0 release. Each of these will have a blog posting to discuss what the changes mean for current and future users. Sometimes I'll aggregate postings, sometimes I won't. The following are some highlights from the past little while of development which has been undertaken by Richard and myself. Each item is, I feel, important enough to warrant commentary, even for those who already use Gitano.

• Lace now supports a sub-define syntax: [foo bar] which makes for simpler rulesets.
• Gitano no longer creates auto_user_XXX and auto_group_XXX Lace predicates
• Gitano no longer supports "basic" simple matches of the form user foo but instead requires a match kind such as group prefix bar-.
• Gitano is gaining i18n/l10n support, though it will not be complete for version 1.0 the basics will be in place.
• Gitano is gaining a much larger integration test suite using yarn.
• Deprecated commands have now been removed from Gitano. (e.g. no more set-owner)
• Gitano has gained PGP/GPG signature verification for commits and tags.

Any number of smaller things have been done which fall below some arbitrary barrier for telling you about. If you're aware of any of them and feel they are worthwhile telling the world about, then please prod me and I'll add an article to the series. Finally it's worth noting that the effort to get all this into Debian Stretch proceeds apace. Of the eight packages needed, at the time of posting: one was already in and has been updated (luxio), three have been accepted into Debian already (supple, clod, lua-scrypt), two are in NEW (gall and lace), and that leaves the newest library (tongue) and then Gitano itself still to go. The Debian FTP team have been awesome in helping me with all this, so thanks go to them.

Yesterday, the motranslator 2.0 has been released. As the version change suggests there are some important changes under the hood. Full list of changes:

• Consistently use camelCase in API
• No more relies on using eval()
• Depends on symfony/expression-language for calculations

As you can see, yesterday announced SimpleMath is not used in the end and I've moved to use existing library. Somehow I misunderstood library description and I thought that it works as PHP, what would be problem for us (or would bring need to add parenthesis around ternary operator as we did with eval()). But this is not the case and ternary operator behaves sane in ExpressionLanguage, so we're good too use it. Anyway if you were using MoTranslator, it might be good idea to upgrade and check if API changes affect you.

Filed under: Debian English phpMyAdmin 0 comments

Yesterday, the motranslator 2.0 has been released. As the version change suggests there are some important changes under the hood. Full list of changes:

• Consistently use camelCase in API
• No more relies on using eval()
• Depends on symfony/expression-language for calculations

As you can see, yesterday announced SimpleMath is not used in the end and I've moved to use existing library. Somehow I misunderstood library description and I thought that it works as PHP, what would be problem for us (or would bring need to add parenthesis around ternary operator as we did with eval()). But this is not the case and ternary operator behaves sane in ExpressionLanguage, so we're good too use it. Anyway if you were using MoTranslator, it might be good idea to upgrade and check if API changes affect you.

Filed under: Debian English phpMyAdmin 0 comments

Authenticating HTTPS clients using TLS certificates has long been very easy to do. The hardest part, in fact, is to create a PKI infrastructure robust enough so that compromised (or otherwise no longer desirable) certificates cannot be used anymore. While setting that up can be fairly involved, it's all pretty standard practice these days. But authentication using a private CA is laughably easy. With apache, you just do something like:

SSLCACertificateFile /path/to/ca-certificate.pem
SSLVerifyClient require

...and you're done. With the above two lines, apache will send a CertificateRequest message to the client, prompting the client to search its local certificate store for certificates signed by the CA(s) in the ca-certificate.pem file, and using the certificate thus found to authenticate against the server. This works perfectly fine for setting up authentication for a handful of users. It will even work fine for a few thousands of users. But what if you're trying to set up website certificate authentication for millions of users? Well, in that case, storing everything in a single CA just doesn't work, and you'll need intermediate CAs to make things not fall flat on their face. Unfortunately, the standard does not state what should happen when a client certificate is signed by an intermediate certificate, and the distinguished name(s) in the CertificateRequest message are those of the certificate(s) at the top of the chain rather than the intermediates. Previously, browsers would not just send out the client certificate, but also send along the certificate that it knew to have signed that client certificate, and so on until it found a self-signed certificate. With that, the server would see a chain of certificates that it could verify against the root certificates in its local trust store, and certificate verification would succeed. It would appear that browsers are currently changing this behaviour, however. With the switch to BoringSSL, Google Chrome on the GNU/Linux platform no longer sent the signing certificates, and instead only sends the leaf certificate that it wants to use for certificate authentication. In the bug report, Ryan Sleevi explains that while the change was premature, the long term plans are for this to be the behaviour not just on GNU/Linux, but on Windows and macOS too. Meanwhile, the issue has been resolved for Chrome 54 (due to be released), but there's no saying for how long. As if that was not enough, the new version of Safari as shipped with macOS 10.12 has also stopped sending intermediate certificates, and expects the web server to be happy with just receiving the leaf certificates. So, I guess it's safe to say that when you want to authenticate a client in a multi-level hierarchical CA environment, you cannot just hand the webserver a list of root certificates and expect things to work anymore; you'll have to hand it the intermediary certificates as well. To do so, you need to modify the SSLCACertificateFile parameter in apache configuration so that it not only contains the root certificate, but all the intermediate certificates as well. If your list of intermediate certificates is rather long, it may improve performance to use SSLCACertificatePath and the c_rehash tool to create a hashed directory with certificates rather than a PEM file, but in essense, that should work. While this works, the problem with doing so is that now the DNs of all the intermediate certificates are sent along with the CertificateRequest message to the client, which (again, if your list of intermediate certificates is rather long) may result in performance issues. The fix for that is fairly easy: add a line like

SSLCADNRequestFile /path/to/root-certificates.pem

where the file root-certificates.pem contains the root certificates only. This file will tell the webserver which certificates should be announced in the CertificateRequest message, but the SSLCACertificateFile (or SSLCACertificatePath) configuration item will still be used for actual verification of the certificates in question. Note though that the root certificates apparently also seem to need to be available in the SSLCACertificatePath or SSLCACertificateFile configuration; if you do not do so, then authentication seems to fail, although I haven't yet found why. I've set up a test page for all of those "millions" of certificates, and it seems to work for me. I've you're trying to use one of those millions of certificates against your own webserver or have a similar situation with a different set of certificates, you might want to make the above changes, too.

For quite some time we've been relying on using eval() function in phpMyAdmin in two places. One of them is gettext library, where we have to evaluate plural forms and second of them is MySQL configuration advisor, which does it's suggestions based on text file (the original idea was to make this file shared with other tools, but it never really worked out). Using eval() in PHP is something what is better to avoid, but we were using it on data we ship, so it was considered safe. On the other side, there are hostings which deny using eval() altogether (as many of exploits are using this function), so it's better to avoid that. I've been looking for options for replacing eval() in motranslator (library we use for handling Gettext MO files) for quite some time, but never found library which would support all operators needed in Gettext plural formulas. Yesterday I finally came to conclusion that writing own library to do this is best approach. This way it can in future extended to work with Advisor as well. Also we can make it pretty lightweight without additional dependencies (what was problem in some existing libraries I've found). To make the story short, this is how SimpleMath was born. As of now, it has grown to version 0.2 (you can use Packagist to install it). For now it's really simple and it can be probably confused by various strange inputs, but it seems for work pretty well for our case. Currently supported features:

• Supports basic arithmetic operations +, -, *, /, %
• Supports parenthesis
• Supports right associative ternary operator
• Supports comparison operators ==, !=, >, <, >=, <=
• Supports basic logical operations &&,
• Supports variables (either PHP style $a or simple n)

Maybe it will be usable for somebody else as well, but even if not, it's the way for us to get rid of using eval() in our codebase. Update It seems that Symfony ExpressionLanguage Component is doing pretty much same, but more flexible and faster, so SimpleMath will be probably dead soon and we will switch to using Symphony component.

Filed under: Debian English phpMyAdmin 4 comments

For quite some time we've been relying on using eval() function in phpMyAdmin in two places. One of them is gettext library, where we have to evaluate plural forms and second of them is MySQL configuration advisor, which does it's suggestions based on text file (the original idea was to make this file shared with other tools, but it never really worked out). Using eval() in PHP is something what is better to avoid, but we were using it on data we ship, so it was considered safe. On the other side, there are hostings which deny using eval() altogether (as many of exploits are using this function), so it's better to avoid that. I've been looking for options for replacing eval() in motranslator (library we use for handling Gettext MO files) for quite some time, but never found library which would support all operators needed in Gettext plural formulas. Yesterday I finally came to conclusion that writing own library to do this is best approach. This way it can in future extended to work with Advisor as well. Also we can make it pretty lightweight without additional dependencies (what was problem in some existing libraries I've found). To make the story short, this is how SimpleMath was born. As of now, it has grown to version 0.2 (you can use Packagist to install it). For now it's really simple and it can be probably confused by various strange inputs, but it seems for work pretty well for our case. Currently supported features:

• Supports basic arithmetic operations +, -, *, /, %
• Supports parenthesis
• Supports right associative ternary operator
• Supports comparison operators ==, !=, >, <, >=, <=
• Supports basic logical operations &&,
• Supports variables (either PHP style $a or simple n)

Maybe it will be usable for somebody else as well, but even if not, it's the way for us to get rid of using eval() in our codebase. Update It seems that Symfony ExpressionLanguage Component is doing pretty much same, but more flexible and faster, so SimpleMath will be probably dead soon and we will switch to using Symphony component.

Filed under: Debian English phpMyAdmin 4 comments

Yesterday evening I was enjoying several features by John Oliver, mostly about the upcoming election in the US (Scandals), but also one of the best features I have heard from him on Guant namo. It sadly reminded me of the completely different landscape in Japan.
Not only since the unprecedented warning to close down biased broadcasters by the Ministry of Internal Affairs and Communication, but ever since Abe is building up his more and more totalitarian control over the country, the freedom of press has been on shaky grounds. Even worse, newspapers and TV outlets restrict themselves to save topics, which means: stupid talk shows, food, and above all praise of Japan and how good, how lovely, how great it is (Make Japan great again!). All this despite the fact that there would be a lot to rumble upon: covering up the truth around Fukushima, mountains of scandals around Olympia 2020, police brutality in Okinawa, the list is long. Only thinking about having something remotely similar to John Oliver on TV in Japan is as unthinkable as Trump donating all his money to a charity for immigrants. Sure enough, John Oliver is one great example out of tons of rubbish in the US, sure enough, but this one example is missing in Japan. What remains are Japanese media stations that crawl into the *** of the government, what a sad state. (Photo credit partially due to ber Arschkriecher)

Two years ago in this post I reference the Seinfeld Streak used in an even earlier post of regular updates to to the Rcpp Gallery:

This is sometimes called Jerry Seinfeld's secret to productivity: Just keep at it. Don't break the streak.

and showed the this first chart of GitHub streaking

Last year a follow-up appeared in this post:

And as it is that time again, here is this year's version:

Special thanks go to Alessandro Pezz for the Chrome add-on GithubOriginalStreak.

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

Hello folks! My team spent hours and hours beating our head against a Sonar deployment problem on Ubuntu Trusty (14.04 LTS). I thought I might share our findings so that you won t have to! As you probably know, Trusty only makes Java Development Kit 1.7 available on the stock installation. The current stable version of the Java is 1.8. The way we install this is to use the OpenJDK PPA, generously uploaded by our dear friend Matthias Klose. To make things even more exciting, a modern Maven is not available on this platform. And so we use the stock Maven 3.3.9 tarball distribution. This tarball distribution does not integrate well with Debian, and so, when we tell the system using sudo update-java-alternatives -s /usr/lib/jvm/java-1.8.0-openjdk-amd64 that we wish to use Java 1.8 as our default system JDK, it does not get the message. The only way to reliably let Maven know which java you wish to use is to set the JAVA_HOME environment variable. In order to do this within the Jenkins environment, one must select the JDK one wishes to use: To make things worse, this option is not, as one might expect, available for editing in a stock Jenkins 2.x installation. In Jenkins 1.x, one would be able to specify which java one wished to use just by specifying openjdk8 in a field. With Jenkins 2.x, the field does not exist unless a configuration option in an unrelated form is set. So! One should first select Manage Jenkins -> Global Tool Configuration: Once this form is open, look for the JDK installations button: Click it very thoroughly just once. You ll be presented with a form into which you may enter details about the various JDKs your build executors may have access to. You ll refer to them in your job configuration by the value of their Name field, and when executing the build, Jenkins will set JAVA_HOME to the value of the (you guessed it) JAVA_HOME field: Once these entries are made, they can be selected in two place. 1) on the ZMQ Event Publisher: 2) in the post-build actions under SonarQube analysis with Maven (advanced) And that s how it s done! Here s the details from my colleague, Thanh: https://lists.fd.io/pipermail/honeycomb-dev/2016-October/000387.html

Seems funny to talk about 20 year old code that was a stop-gap measure to provide a bridging function the kernel had not (as yet) got, but here it is, my old bridge code. When I first started getting involved in Free Software, I was also involved with hamradio. In 1994 I release my first Free Software, or Open Source program called axdigi. This program allowed you to digipeat . This was effectively source route bridging across hamradio packet networks. The code I used for this was originally network sniffer code to debug my PackeTwin kernel driver but got frustrated at there being no digipeating function within Linux, so I wrote axdigi which is about 200 lines. The funny thing is, back then I thought it would be a temporary solution until digipeating got put into the kernel, which it temporarily did then got removed. Recently some people asked me about axdigi and where there is an official place where the code lives. The answer is really the last axdigi was 0.02 written in July 1995. It seems strange to resurrect 20 year old code but it is still in use; though it does show its age. I ve done some quick work on getting rid of the compiler warnings but there is more to do. So now axdigi has a nice shiny new home on GitHub, at https://github.com/csmall/axdigi

From last month s toybox of distractions, I ve spent time with GitLab CI, Ansible, Prometheus and OpenShift. GitLab CI is a lot like Travis CI, and a little less like Jenkins. When a commit is pushed to the repository in GitLab, and the branch contains a .gitlab-ci.yml file, a GitLab CI runner will check out the repository, and follow the instructions in that file. Useful for configuration syntax checks, unit tests, and puppet environment deployments. I ve mostly used Ansible for orchestration, performing tasks across a number of nodes. I ve used it much configuration management for a bit, and from what I see, it can do that rather well, too. I ve used Puppet in production for a bit (I committed revision 1 in the old puppet configuration management repository at work in 2007-07-04). A new perspective on configuration management is good. Prometheus is a master-node stats gatherer and presenter. It does a single HTTP GET to fetch all metrics in a single request. I ve used Munin for a long, long time, and while the plugin ecosystem is far larger for Munin, the Prometheus master scales much better (millions of metrics per minute on a modern machine). I use Grafana to present graphs from Prometheus and logs from Elasticsearch in the same dashboard. Prometheus can collect data from a munin node, using a munin node exporter. Last week I got training in OpenShift, which was an eye-opener. I ve used Docker for a good while, and planned to introduce Kubernetes, as well as an imperial buttload of shell scripts to keep it all automated. Thankfully, OpenShift Origin already includes Kubernetes and does the required automation. An OpenShift cluster is now being added to the core infrastructure to do the required care and feeding of the herd of APIs and microservices written over the years. Bunch it together behind an API Management Gateway, and you should be able to label the whole thing Microservice Architecture . I m not running out of fun things to do for a while.