gettz is now on CRAN in its initial release 0.0.1. It provides a possible fallback in situations where Sys.timezone() fails to determine the system timezone. That can happen when e.g. the file /etc/localtime somehow is not a link into the corresponding file with zoneinfo data in, say, /usr/share/zoneinfo. Duane McCully provided a nice StackOverflow answer with code that offers fallbacks via /etc/timezone (on Debian/Ubuntu) or /etc/sysconfig/clock (on RedHat/CentOS/Fedora, and rumour has it, BSD* systems) or /etc/TIMEZONE (on Solaris). The gettz micro-package essentially encodes that approach so that we have an optional fallback when Sys.timezone() comes up empty. In the previous paragraph, note the stark absense of OS X where there seems nothing to query, and of course Windows. Contributions for either would be welcome. 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.

Relatively quickly after version 0.4.5 of RProtoBuf was released, we have a new version 0.4.6 to announce which appeared on CRAN today. RProtoBuf provides R bindings for the Google Protocol Buffers ("Protobuf") data encoding and serialization library used and released by Google, and deployed as a language and operating-system agnostic protocol by numerous projects. This version contains a contributed bug-fix pull request covering conversion of zero-length vectors, and adding native support for S4 objects. At the request / suggestion of the CRAN maintainers, it also uncomments a LaTeX macro in the vignette (corresponding to our recent JSS paper paper) which older R versions do not (yet) have in their jss.cls file.

Changes in RProtoBuf version 0.4.6 (2016-09-08)

• Support for serializing zero-length objects was added (PR #18 addressing #13)
• S4 objects are natively encoded (also PR #18)
• The vignette based on the JSS paper no longer uses a macro available only with the R-devel version of jss.cls, and hence builds on all R versions

CRANberries also provides a diff to the previous release. The RProtoBuf page has an older package vignette, a 'quick' overview vignette, a unit test summary vignette, and the pre-print for the JSS paper. Questions, comments etc should go to the GitHub 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.

sunweaver sighs... This short post is to inform all Debian MATE users that the recent GTK-3+ upload to Debian (GTK-3+ v3.21) broke most parts of the MATE 1.14 desktop environment as currently available in Debian testing (aka stretch). This raises some questions here on the MATE maintainers' side... Questions

1. Isn't GTK-3+ a shared library? This one was rhetorical... Yes, it is.
2. One that breaks other application with every point release? Well, unfortunately, as experience over the past years has shown: Yes, this has happened several times, so far and it happened again.
3. Why is it that GTK-3+ uploads appear in Debian without going through a proper transition? This question is not rhetorical. If someone has an answer, please enlighten me.

Potential Counter Measures For Debian MATE users running on Debian testing: This is untested, but it is quite likely that your MATE desktop environment will work again, once you have reverted your GTK-3+ library back to v3.20. For obtaining old Debian package versions, please visit the https://snapshots.debian.org site. Prospective The MATE 1.16 release is expected for Sep 20th, 2016. We will do our best to provide MATE 1.16 in Debian before this month is over. MATE 1.16 will again run smoothly (so I heard) on GTK-3+ 3.21.
light+love
sunweaver (who is already scared of the 3.22 GTK+ release, luckily the last development release of the GTK+ 3-series)

Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you re interested in Android, Java, Games and LTS topics, this might be interesting for you. Debian Android

• This was the final month of the Google Summer of Code and the students achieved the main goal of packaging the Android SDK. It is now possible to build Android apps on Debian with packages only from the main distribution (apt install android-sdk). Chirayu Desai fixed the last remaining issue in android-platform-system-core (#827216). That also means apktool is now ready to rebuild Android applications. You can find more information about the students work at wiki.debian.org and on their individual pages Chirayu Desai, Kai-Chung Yan and Mouaad Aallam.
• I sponsored a new upstream release (2.2.0) of apktool for Chirayu Desai.
• I also reviewed and sponsored the following packages for Kai-Chung and Chirayu Desai (RC bug fixes and new upstream releases): android-platform-dalvik, android-platform-frameworks-base, android-sdk-meta.

Debian Games

• I started the month with package updates for foobillardplus, tuxpuck, etw, cube2, cube2-data and neverball.
• I released a new revision of triplane to fix a reproducible build issue.
• I packaged a new upstream release of springlobby.
• I fixed GCC-6 FTBFS bugs in stormbaancoureur and love and updated both packages to use modern Debian helpers (stormbaancoureur needed it badly).
• I invested some time to package Liquidwar 6 (#680023) and attached my preliminary work to the bug report. Liquidwar 6 has been in the works for a long time now and is a complete rewrite of the original Liquidwar game. The graphics are much more polished and dozens of new levels are available. I didn t complete my work on Liquidwar 6 because, at least on my system, the game constantly consumes 100% CPU time. Network modus isn t finished yet and it still depends on SDL 1. Nowadays I m only interested in SDL 2 (or similar) games though because I think the library is more future-proof and SDL 1 will probably become a burden for future maintainers.
• In the second half of the month I fixed a couple of RC bugs again caused by the Boost 1.61 transition and yes still more GCC-6 bugs : libclaw (GCC-6 and Boost 1.61 issues, new upstream release), freeorion (Boost 1.61 FTBFS, #833773. This one was arguably a regression in Boost 1.61 and I filed #833794 because of it), pokerth (GCC-6 RC bugs. I also took the opportunity to implement systemd support for pokerth-server and I modified the package to run the server as the _pokerth system user out-of-the-box.), 0ad (missing build-dependency on python).
• Even music packages can pile up bug reports, so I went ahead and updated fretsonfire-songs-muldjord and fretsonfire-songs-sectoid.
• In the last days of August 2016 I packaged a new upstream release of redeclipse and redeclipse-data, a first-person shooter. The older version was network-incompatible and long unsupported.

Debian Java

• I packaged new upstream releases of libjide-oss-java, undertow, jboss-xnio, hawtjni.
• I fixed RC bugs in libfreemaker-java, airlift-slice, japi-compliance-checker (was already fixed by Emmanuel Bourg but never uploaded), lucene2, libbtm-java, javassist, commons-math, libslf4j-java, surefire, maven-invoker, maven-scm and sweethome3d-furniture-editor.
• I triaged RC bug #834744 in xmlgraphics-commons and lowered the severity because the build failure was not reproducible in a clean cowbuilder environment. Another RC bug was reported against mina2 but I also couldn t reproduce the test failure hence I lowered the severity and marked #834682 as unreproducible.
• Another RC bug was reported against bookkeeper, #835277, allegedly the issue was caused by a missing artifact. After some investigation it turned out that the recent update of libprotobuf-java, one of bookkeeper s build-dependencies, used the wrong pom.xml and thus different Maven coordinates for the artifact. I filed #835358 and later #835514 against libprotobuf-java and both issues got resolved quickly.
• I reported #835354 against libitext-java because the package was uninstallable.
• I sponsored a new upstream release of freeplane for Felix Natter.

Debian LTS This was my seventh month as a paid contributor and I have been paid to work 14,75 hours on Debian LTS, a project started by Rapha l Hertzog. In that time I did the following:

• From 01. August to 07. August I was in charge of our LTS frontdesk. I triaged CVEs in wordpress, mysql-5.5, libsys-syslog-perl, libspring-java, curl and squid and answered questions on the debian-lts mailing list.
• DLA-586-1. Issued a security update for curl fixing 2 CVE.
• DLA-585-1. Announced the security update for firefox-esr which was prepared by Mike Hommey.
• I was involved in an embargoed security issue that currently affects two source packages in Wheezy. The update will be released on 15. September 2016 and will be coordinated with Debian s Security Team and other distributions. I will add more information next month.
• DLA-610-1. I spent most of the time this month on triaging and fixing security issues in tiff3, a library providing support for the Tagged Image File Format (TIFF). 99 source packages currently build-depend on this library in Wheezy. In total I triaged 35 CVEs and fixed 23 of them. I could confirm that CVE-2015-1547, CVE-2016-5322, CVE-2016-5314, CVE-2016-5315, CVE-2016-5316, CVE-2016-5317 and CVE-2016-5320 were duplicates of other CVEs fixed in this update. The update hardened the library and fixed possible denial-of-service (application crash) and arbitrary code execution issues. I tested whenever possible against the provided reproducers (malicious tiff images). The tiff3 package now includes all currently available patches. Most of the current open vulnerabilities do not directly affect end-users since no binary package has been provided for the tiff tools in Wheezy. However they can still pose a threat to people who build these tools from source manually. Though the majority of users should not be affected. It is also unlikely that the remaining issues will be fixed by tiff s upstream developers since they decided to remove the affected applications from newer releases but again most of them can t be exploited since the tools are not built by default in this version.

Non-maintainer uploads

• I did a NMU for pacman fixing one GCC-6 RC bug.

QA

• I packaged a new upstream release of pygccxml and worked around a RC bug that threatened to remove spring. For similar reasons I filed #835121 against castxml that got quickly fixed by Gert Wollny.

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. This months is rather light since I was away in vacation for two weeks. Kali related work The new pkg-security team is working full steam and I reviewed/sponsored many packages during the month: polenum, accheck, braa, t50, ncrack, websploit. I filed bug #834515 against sbuild since sbuild-createchroot was no longer usable for kali-rolling due to the embedded dash. That misfeature has been reverted and implemented through an explicit option. I brought the attention of ftpmasters on #832163 since we had unexpected packages in the standard section (they have been discovered in the Kali live ISO while we did not want them). I uploaded two fontconfig NMU to finally push to Debian a somewhat cleaner fix for the problem of various captions being displayed as squares after a font upgrade (see #828037 and #835142). I tested (twice) a live-build patch from Adrian Gibanel Lopez implementing EFI boot with grub and merged it into the official git repository (see #731709). I filed bug #835983 on python-pypdf2 since it has an invalid dependency forbidding co-installation with python-pypdf. I orphaned splint since its maintainer was missing in action (MIA) and immediately made a QA upload to fix the RC bug which kicked it out of testing (this package is a build dependency of a Kali package). django-jsonfield I wrote a patch to make python-django-jsonfield compatible with Django 1.10 (#828668) and I committed that patch in the upstream repository. Distro Tracker I made some changes to make the codebase compatible with Django 1.10 (and added Django 1.10 to the tox test matrix). I added a Debian Maintainer Dashboard link next to people s name on request of Lucas Nussbaum (#830548). I made a preliminary review of Paul Wise s patch to add multiarch hints (#833623) and improved the handling of the mailbot when it gets MIME Headers referencing an unknown charset (like cp-850 , Python only knows of cp850 ) I also helped Peter Palfrader to enabled a .onion address for tracker.debian.org, see onion.debian.org for the full list of services available over Tor. Misc stuff I updated my letsencrypt.sh salt formula to work with the latest version of letsencrypt.sh (0.2.0) I merged updated translations for the Debian Administrator s Handbook from weblate.org and uploaded a new version to Debian. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

The seventh update in the 0.12.* series of Rcpp just arrived on the CRAN network for GNU R as well as in Debian. This 0.12.7 release follows the 0.12.0 release from late July, the 0.12.1 release in September, the 0.12.2 release in November, the 0.12.3 release in January, the 0.12.4 release in March, the 0.12.5 release in May, and the 0.12.6 release in July --- making it the eleventh release at the steady bi-montly release frequency. Keeping with the established pattern, this is again more of a maintenance release which addresses small bugs, nuisances or documentation issues without adding any major new features. One issue that got to a few people was our casual use of NORET in the definition of Rcpp::stop(). We had (ahem) overlooked that NORET is only defined by R 3.2.0 or later, and several folks trying to build on older releases of R (why?) got bitten. Well, at least we have a new record for most frequently reported bug ... Kidding aside, this is now fixed. Rcpp has become the most popular way of enhancing GNU R with C or C++ code. As of today, 759 packages on CRAN depend on Rcpp for making analytical code go faster and further. That is up by well over fifty packages since the last release in mid-July! We are once again fortunate to have a number of pull request, from first-timers to regulars. James "coatless" Balamuta in particular relentlessly pushed for better documentation and cleanup of numerous dangling issue tickets. Artem Klevtsov also contributed again. Qiang, Kevin and I also got some changes in for the Rcpp Core team. More details are again below.

Changes in Rcpp version 0.12.7 (2016-09-04)

• Changes in Rcpp API:
  • The NORET macro is now defined if it was not already defined by R itself (Kevin fixing issue #512).
  • Environment functions get() & find() now accept a Symbol (James Balamuta in #513 addressing issue #326).
  • Several uses of Rf_eval were replaced by the preferred Rcpp::Rcpp_eval (Qiang in PR #523 closing #498).
  • Improved Autogeneration Warning for RcppExports (James Balamuta in #528 addressing issue #526).
  • Fixed invalid C++ prefix identifiers in auto-generated code (James Balamuta in #528 and #531 addressing issue #387; Simon Dirmeier in #548).
  • String constructors now set default UTF-8 encoding (Qiang Kou in #529 fixing #263).
  • Add variadic variants of the RCPP_RETURN_VECTOR and RCPP_RETURN_MATRIX macro when C++11 compiler used (Artem Klevtsov in #537 fixing #38).
• Changes in Rcpp build system
  • Travis CI is now driven via run.sh from our fork, and deploys all packages as .deb binaries using our PPA where needed (Dirk in #540 addressing issue #517).
• Changes in Rcpp unit tests
  • New unit tests for random number generators the R namespace which call the standalone Rmath library. (James Balamuta in #514 addressing issue #28).
• Changes in Rcpp Examples:
  • Examples that used cxxfunction() from the inline package have been rewritten to use either sourceCpp() or cppFunction() (James Balamuta in #541, #535, #534, and #532 addressing issue #56).

Thanks to CRANberries, you can also look at a diff to the previous release. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads page, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

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

Wow, a mouthful of a title, for a much simpler post. Up until earlier this year, I had only one sport GPS device, and that was a watch. Made sense, as my "main" sport was running (not that I did it very consistently). Upgraded over a few generations of Garmins, I mainly used it to record my track and statistics (pace, heart rate, etc.) The newest generation of watch and heart rate monitor even give more statistics (left-right leg balance, ground contact time, so on). Most of this data can be looked at while running, but only as an exception; after all, it's very hard to run with one hand up in front of your face. The other useful features guided workouts and alerts during normal runs I've used, but not consistently. So when I started biking a bit more seriously, I wondered whether it would make sense to buy a bike computer. The feature intersection between watch and bike GPS is quite large, so clearly this is a "want" not a "need" by far. Reading forum posts showed the same question repeated multiple times What convinced me to nevertheless buy such a bike GPS were the mapping/routing features. A bike GPS with good routing features, or even just maps on which tracks can be overlayed, can certainly ease the discovery of new routes. After a few months of use, my most useful feature is one that I didn't expect. While the mapping is useful and I do use it, the one that actually is significantly better than my watch is the large display with data fields that I can trivially check almost continuously on road biking, and during technically easy climbing sections for mountain biking. My setup looks like this: It's a 9-field setup; the Edge 1000 can go to 10, but I like "headline" field. The watch can only go to four, and is basically not usable during rides, unless one would use a quick-release kit for mounting on the handle bar. This setup allowed me to learn much better my physical capabilities, why I sometimes run out of energy, and how the terrain affects me. Random things that I learned:

• Gradient: on a road bike, +2% grade is just fun, -2% grade is excellent; on a mountain bike, -2% is somewhat felt but not so much. Going above 6-8% on a mountain bike is tiring, and above 15% means I can bike but I will dip too much into my reserves. Not sure yet what the numbers are on a road bike
• Cadence: on flatter routes, my most efficient cadence is 102-108 RPM; between 98-102 I feel I need to extra push, and below 98 I know (now) my muscles will get tired too early; on significant ascents, I don't have enough gearing to sustain such an RPM, and that tires me faster. On medium distance flat rides (~70Km), I usually do ~100 averaged over the whole distance.
• Heart rate: below ~140 is recovery, ~140-150 is sustained effort, ~150-160 is short-duration pushes, and anything above ~160 will eat through my anaerobic budget, which means I'd better stop soon or my performance for the rest of the ride will suffer; this, surprisingly, matches quite well with my latest run lactate threshold (as computed by my watch), which was 161bpm.
• Condition: when cruising without pedalling or when stopping, I can ballpark my current condition very easily by seeing how fast my heart rate goes down.
• Total ascent: useful for two things: to make me proud how much I've already climbed, and if I know the total ascent for the route either make me despair how much I have left, or make me happy that the climbs are done

Seeing all this data only after the ride is less useful since you don't remember exactly how you felt during specific points in the ride. But as real-time data, one can easily see/feel the correlation between how the body feels and what data says. One thing that would be also useful would be real-time power data (3 sec average, not instantaneous) to correlate even better with the body state. I now use heart rate and cadence as a proxy for that, but being able to see actual power numbers would increase the usefulness of the data even more. Unfortunately, none of these makes the climbs easier. But at least it allows me to understand why one climb feels hard and another easy (relatively speaking). I wonder if, and how this could be applied to running; maybe with smart glasses? Conclusion: yes, I do recommend a bike computer with a large display (to be able to see many fields at once). Just in case one has disposable income at hand and doesn't know which hobby to spend it on

FTP assistant This month I marked 257 packages for accept and rejected only 26. Seems to be that I mostly choosed the high quality packages this month. I also sent 12 emails to maintainers asking questions. Debian LTS This was my twenty-sixth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. This month my all in all workload has been 14.75h. Again, most of the time I choosed packages, where at the end the vulnerable code of the corresponding CVE was not present in the Wheezy version. So I could mark several CVEs for lshell and wget as not-affected, without doing an upload. Unfortunately I had to give up working on chicken. My scheme abilities appear to be rather rusty. Further, I uploaded a test version for php5 that takes care of 17 CVEs and as requested by the LTS users, two additional bugs. After all tests are passed, I will do a real upload with DLA. This month I also had another term of frontdesk work. Other stuff For the Alljoyn framework I fixed a compile issue with gcc 6 and could close RC-bugs
#831127, #831091, and #831198.
My patch was also accepted by upstream. Unfortunately a bug in gtest resulted in #833636. As gcc 6 is the default compiler now in testing, I could also close RC bug #831106.

A couple of weekends back, we had an awesome time at Jonathan and Charlene's wedding. I'd have blogged sooner, but I had to wait for this photo of the happy couple with the Debian gang... :-) Unfortunately, somebody let Charlene hide at the back! Follow the link for more photos...

Me and Ana travelled to Cambridge last weekend for the Debian UK BBQ. We travelled by train and it was a rather scenic journey. In the past, on long journeys, I ve used APRS-IS to beacon my location and plot my route but I have recently obtained the GPS module for my Yaesu VX-8DE and I thought I d give some real RF APRS a go this time. While the APRS IGate coverage in the UK is a little disappointing, as is evidenced by the map, a few cool things did happen. I recieved a simplex APRS message from a radio amateur 2M0RRT with the text test test IO86ML (but unfortunately didn t notice until we d long passed by, sorry for not replying!) and quite a few of my packets, sent from a 5 watt handheld in Cambridge, were heard by the station M0BPQ-1 in North London (digipeated by MB7UM).

My APRS Position Reports for the Debian UK BBQ 2016

Some of you will know that since my trip to the IETF in Berlin, I ve been without a working laptop (it got a bit smashed up on the plane). This also caused me to miss the reminder to renew the expiry on my old GPG key, which I have now retired. My new GPG key is not yet in the Debian keyring but can be found in the Tor Project keyring already. A request has already been filed to replace the key in the Debian keyring, and thanks to attendees at the BBQ, I have some nice shiny signatures on my new key. (I ll get to returning those signatures as soon as I can.) We ve been making a lot of progress with Debian Live and the BBQ saw live- tasks being uploaded to the archive. This source package builds a number of metapackages, each of which configures a system to be used an a live CD for a different desktop environment. I would like for as much of the configuration that can be done within the image as possible to be done within the image, as this will help with reproducibility. A new upload for live-wrapper should be coming next week, and this version will allow these live-task-* packages to be used to build images for testing. I hope to have weekly builds for the live images running very soon. As I ve been without a computer for a while, I m just getting back into things now, so expect that I ll be slow to respond to communication for a while but I ll also be making commits and uploads and trying to clear this backlog as quickly as I can (including my Tor Project backlog).

A Few Useful Mental Tools from Richard Feynman [archive]

These tricks show Feynman taking the method of thought he learned in pure science and applying it to the more mundane topics most of us have to deal with every day.

Pasta [archive]

A comprehensive introduction to pasta, to keep at hand in case I meet someone who has little familiarity with it.

MPTP: One Designer Drug and Serendipity [archive]

Abstract: Through an unlikely series of coincidences and fortunate accidents, the development of Parkinson s disease in several illicit drug users was traced to their use of a meperidine analog contaminated with 1-methyl-4-phenyl-1,2,3,6-tetrahydropyridine (MPTP). The discovery of a chemical capable of producing animal models of the disease has revitalized research efforts and resulted in important new information. The serendipitous finding also prompted consideration of what changes seem advisable if designer drugs are to be dealt with more efficaciously.

The Debunking Handbook: now freely available for download

The Debunking Handbook, a guide to debunking misinformation, is now freely available to download. Although there is a great deal of psychological research on misinformation, there's no summary of the literature that offers practical guidelines on the most effective ways of reducing the influence of myths.

Faulty neon light jams radio appliances [archive]

An apparent interference source began plaguing wireless vehicle key fobs, cell phones, and other wireless electronics. Key fob owners found they could not open or start their vehicles remotely until their vehicles were towed at least a block away, nor were they able to call for help on their cell phones when problems occurred

Calvin & Muad'Dib

Calvin & Hobbes with text taken from Frank Herbert's Dune. It's been around since 2013 and I consistently found it moving and deep.

When Birds Attack - Bike Helmet Hacks [archive]

Australian magpies attacking cyclists has propted several creative adaptations, including attaching an afro wig to the bike helmet.

Quite on schedule (just one day later), Weblate 2.7 is out today. This release brings Subversion support or improved zen mode. Full list of changes:

• Documentation improvements.
• Translations.
• Updated bundled javascript libraries.
• Added list_translators management command.
• Django 1.8 is no longer supported.
• Fixed compatibility with Django 1.10.
• Added Subversion support.
• Separated XML validity check from XML mismatched tags.
• Fixed API to honor HIDE_REPO_CREDENTIALS settings.
• Show source change in zen mode.
• Alt+PageUp/PageDown/Home/End now works in zen mode as well.
• Add tooltip showing exact time of changes.
• Add option to select filters and search from translation page.
• Added UI for translation removal.
• Improved behavior when inserting placeables.
• Fixed auto locking issues in zen mode.

If you are upgrading from older version, please follow our upgrading instructions. You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Aptoide, FreedomBox, Weblate itself and many other projects. Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure. Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English Gammu phpMyAdmin SUSE Weblate 0 comments

A few short weeks after the 0.4.4 release of RProtoBuf, we are happy to announce a new version 0.4.5 which appeared on CRAN earlier today. RProtoBuf provides R bindings for the Google Protocol Buffers ("Protobuf") data encoding library used and released by Google, and deployed as a language and operating-system agnostic protocol by numerous projects. This release brings support to the recently-release 'version 3' Protocol Buffers standard, used e.g. by the (very exciting) gRPC project (which was just released as version 1.0). RProtoBuf continues to supportv 'version 2' but now also cleanly support 'version 3'.

Changes in RProtoBuf version 0.4.5 (2016-08-29)

• Support for version 3 of the Protcol Buffers API
• Added 'syntax = "proto2";' to all proto files (PR #17)
• Updated Travis CI script to test against both versions 2 and 3 using custom-built .deb packages of version 3 (PR #16)
• Improved build system with support for custom CXXFLAGS (Craig Radcliffe in PR #15)

CRANberries also provides a diff to the previous release. The RProtoBuf page has an older package vignette, a 'quick' overview vignette, a unit test summary vignette, and the pre-print for the JSS paper. Questions, comments etc should go to the GitHub 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.

What happened in the Reproducible Builds effort between Sunday August 21 and Saturday August 27 2016: GSoC and Outreachy updates

• Satyam Zode's final report for GSOC 2016

Packages reviewed and fixed, and bugs filed

• #834976 filed against auto-apt-proxy by Chris Lamb.
• #835637 filed against myghty by Chris Lamb.
• #835061 filed against varnish by Chris Lamb.
• #835633 filed against pleiades by Chris Lamb.
• #835625 filed against nikwi by Chris Lamb.
• #835263 filed against binutils-m68hc1x by Chris Lamb.
• #835448 filed against eekboek by Chris Lamb.
• #835143 filed against ttf-tiresias by Chris Lamb.
• #835637 filed against myghty by Chris Lamb.
• #835495 filed against broccoli by Chris Lamb.
• #835129 filed against dateutils by Chris Lamb.
• #835051 filed against sheepdog by Chris Lamb.
• #835145 filed against udpcast by Chris Lamb.
• #834983 filed against eyed3 by Chris Lamb.
• #835617 filed against congress by Chris Lamb.
• #835376 filed against lilyterm by Chris Lamb.
• #835130 filed against ircd-ircu by Chris Lamb.
• #835262 filed against radare2 by Chris Lamb.
• #835193 filed against phpdox by Chris Lamb.
• #835265 filed against argyll by Chris Lamb.
• #835259 filed against quvi by Chris Lamb.
• #835371 filed against dispcalgui by Chris Lamb.
• #835147 filed against javatools by Chris Lamb.
• #834988 filed against twitter-bootstrap3 by Chris Lamb.
• #835463 filed against fdroidserver by Chris Lamb.
• #835646 filed against dh-lua by Chris Lamb.
• #835447 filed against libmodule-build-withxspp-perl by Chris Lamb.
• #835418 filed against libfm by Chris Lamb.
• #835143 filed against ttf-tiresias by Chris Lamb.
• #834993 filed against oss4 by Reiner Herrmann.

Reviews of unreproducible packages 10 package reviews have been added and 6 have been updated this week, adding to our knowledge about identified issues. A large number of issue types have been updated:

• Add captures_build_path issue and some packages affected by it
• Add golang_compiler_captures_build_path_in_binary and move obfs4proxy to it
• Move 7 golang packages from captures_build_path to golang_compiler_captures_build_path_in_binary
• Add new:
  • random_order_in_lua_version_substvar
  • href_links_mangled_by_node_marked
  • perl_extutils_xspp_captures_build_path
  • timestamp_added_by_java_util_properties
• Fixes for issues created:
  • perl_extutils_xspp_captures_build_path
  • random_order_in_lua_version_substvar
  • random_order_in_javahelper_substvars
• Patch for zope_random_field_order_in_dzproduct uploaded.
• Rename:
  • use_epydoc randomness_in_documentation_generated_by_epydoc so it at least matches the others
  • random_order_in_javahelper_depends issue to random_order_in_javahelper_substvars
• Fix the link for the golang issue, previous link is for random_build_path_by_golang_compiler a different issue
• Add a tip regarding how to call ./configure for rust
• Add offending source line for gcc-defaults.

Weekly QA work 29 FTBFS bugs have been reported by:

• Chris Lamb (27)
• Daniel Stender (1)
• Santiago Vila (1)

diffoscope development

• Chris Lamb:
  • Add tests for skip_unless_tool_exists helper.
  • comparators/elf.py: Specify string format arguments as logging function parameters, not using interpolation.
  • presenters/html:
    • Use html.escape over xml.sax.saxutils.escape.
    • Don't use unsafe cgi.escape method as its quote kwarg -- which enables escaping of quotation marks -- is False by default.
  • Tidy imports in Debian comparator and tests.
  • Skip Haskell tests if GHC version does not match. (Closes: #835055)
  • Use pytest.xfail over assert False.
  • Use the debian_fallback.X as the fallback for debian.DotBuildinfoFile (not debian.X).
  • Rename skip_unless_tool_exists -> skip_unless_tools_exist and fix logic.
  • Avoid ugly DRY violations in diffoscope.comparators.__init__ by dynamically importing classes via a single list.
• Satyam Zode:
  • Improve diffoscope behaviour for .changes
• Mattia Rizzolo:
  • Be even more verbose about failing tests
  • d/control: alternate build-dependency on default-jdk-headless default-jdk, to ease backporting to older debian releases
  • add default-jdk to the alternate packages for javap for Debian; default-jdk-headless is not available in older Debian releases
  • in the tests only, normalize xxd's output so that we can compare jessie's xxd with stretch's
  • tests:
    • skip test_squashfs.py.test_superblock if squashfs is too old
    • rewrite tool_older_than() into skip_unless_tool_is_older_than()
    • factor out a tools_missing() function
• J r my Bobbio:
  • Properly skip test requiring python-debian when unavailable
• Ximin Luo:
  • Add a --no-max flag to disable all limits and have max_report_size also honour 0 to mean "no limit"
  • Actually only scan whole file when filename ends in ".rom"
  • Show the timestamp when logging so I know which steps take longer

Holger also created another test job for diffoscope on jenkins.debian.net, so that now also all commits to branches other than master are being tested. strip-nondeterminism development strip-nondeterminism 0.023-1 was uploaded by Chris Lamb:

 * Support Android .apk files with the JAR normalizer.
 * handlers/png.pm: Drop unused Archive::Zip import
 * Remove hyphen from non-determinism and non-deterministic.
 * javaproperties.pm: Match more styles of .properties and loosen filename matching.
 * Improve tests:
   - Make fixture runner generic to all normalizer types.
   - Replace (single) pearregistry test with a fixture.
   - Set a canonical time for fixture tests.
   - Add gzip testcase fixture.
   - Replace t/javadoc.t with fixture
   - Replace t/ar.t with a fixture.
   - t/javaproperties: move pom.properties and version.properties tests to fixtures
   - t/fixtures.t: move to using subtests
   - t/fixtures.t: Explicitly test that we can find a normalizer
   - t/fixtures.t: Don't run normalizer if we didn't find one.

strip-nondeterminism 0.023-2 uploaded by Mattia Rizzolo to allow stderr in autopkgtest. disorderfs development

• Chris Lamb:
  • Add --sort-dirents=yes no option for forcing deterministic.
  • Testsuite:
    • Add tests for sorting and reversing directory entries.
    • shuffle: Test that --shuffle-dirents works as directed.
    • common: Factor out utility to get variations from mount target.
    • common: Factor out "Fail" utility.

tests.reproducible-builds.org Debian:

• Since we introduced build path variations for unstable and experimental last week, our IRC channel has been flooded with notifcations about packages becoming unreproducible - and you might have noticed some of your packages having become unreproducible recently too. To make our IRC more bearable again, notifications for status changes on i386 and armhf have been disabled, so that now we only get notifications for status changes in unstable. (h01ger)
• Link to jenkins documentation in every page (h01ger)
• The "pre build" check, whether a node is up, now also detects if a node has a read-only filesystem, which sometimes happens on some broken armhf nodes. (h01ger)
• To further improve monitoring of those armhf nodes Work to make them send mails (through an ISP which is blocking outgoing mails) has been started and should be finished next week. (h01ger)
• As one of the armhf nodes (opi2a) is acting strange, a workaround has been added to make it's deployment work despite that. (h01ger)
• Collapse whitespace to avoid ugly "trailing underlines" in hyperlinks for diffoscope results and pkg sets (Chris Lamb)
• Give details HTML elements "cursor: pointer" CSS property to highlight they are clickable. (Chris Lamb)
• The db connection timeout has been raised to a minute when using SQLAlchemy too. (h01ger).

Somewhat related to reproducible builds there has been a first Debian jenkins team maintainance meeting on the #debian-qa IRC channel, to discuss current issues with the setup and to start the work of migrating jenkins.debian.net to jenkins.debian.org. The next meeting will take place on September 28th 2016 at 19 UTC. Misc. This week's edition was written by Chris Lamb and Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.

FOAAS upstream came out with release 1.1.0 earlier last week. Tyler Hunt was kind enough to provide an almost immediate pull request adding support for the extended capabilties. Following yesterday's upload we now have version 1.1.0 of rfoaas on CRAN. It brings six more accessors: maybe(), blackadder(), horse(), deraadt(), problem(), cocksplat() and too(). As usual, CRANberries provides a diff to the previous CRAN release. Questions, comments etc should go to the GitHub issue tracker. More background information is on the project page as well as on 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.

A maintenance release of the RcppCNPy package is now on CRAN. RcppCNPy provides R with read and write access to NumPy files thanks to the cnpy library by Carl Rogers. This release just updates a few package internals such as the vignette, the DESCRIPTION and the README.md file as well as under Travis script used for continuous integration.

Changes in version 0.2.5 (2016-08-26)

• Synchronized code with the cnpy repository
• Updated vignette
• Expanded DESCRIPTION

CRANberries also provides a diffstat report for the latest release. As always, feedback is welcome and the best place to start a discussion may be the GitHub issue tickets page.

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

Once I got CI working on multiple platforms the obvious next step was to be able to aggregate coverage reports across them. This should not be that hard, right? Well I've spent couple of hours on that during last few days. On Linux and OSX it was pretty much straightforward. Both GCC and Clang do support coverage, so it's just matter of configuring them properly and collect the coverage reports. I've used own solution for that in past and that was really far from working well (somehow I never managed to get coverage fully uploaded to Codecov). Fortunately there exists CMake script called CMake-codecov which does all needed work and works out of the box on GCC and Clang (even on OSX). Well it works on Travis only once you update the compilers and install llvm-cov tool. The Windows part on AppVeyor was much harder for me. This can be heavily accounted to lack of my experience with Windows and especially development on Windows in past ten years (probably even more). First challenge was to find something what can generate code coverage there. After lot of googling I've settled down on OpenCppCoverage what seems to be the only free solution I was able to find. The good thing is that it can generate coverage in Cobertura format that Codecov undestands. There are also bad things that I've learned. First of all it's quite hard to integrate this with CTest. There is no support for wrapping test calls in custom commands, so I've misused the memory checks for that purpose. I've written small python script which pretends the valgrind interface and does call OpenCppCoverage in the background. Now I had around 800 coverage files (one for each test case) and we need to deal with them somehow. The Codeconv command line client doesn't deal wit this out of the box so the obvious choice was to merge them before upload. There even seems to be script doing that, but unfortunately trying that on our coverage data make it nowhere near completion within hour, so that's not really good choice. Second thing I've tried was merging binary coverage in OpenCppCoverage and then exporting to Cobertura format. Obviously Gammu is special project as all I got from this attempt was crashing OpenCppCoverage (it did merge some of the coverages, but it failed in the end without indicating any error). In the end I've settled down to uploading files in chunks to Codecov. This seems to work quite okay, though is a bit slow, mostly due to way how Codecov bash uploader prepares data to upload (but this will be hopefully fixed soon). Anyway the goal has been reached, both Windows and Linux code shows in coverage reports.

Filed under: Debian English Gammu 0 comments

Another Armadillo 7.* release -- now at 7.400. We skipped the 7.300.* serie release as it came too soon after our most recent CRAN release. Releasing RcppArmadillo 0.7.400.2.0 now keeps us at the (roughly monthly) cadence which works as a good compromise between getting updates out at Conrad's sometimes frantic pace, while keeping CRAN (and Debian) uploads to about once per month. So we may continue the pattern of helping Conrad with thorough regression tests by building against all (by now 253 (!!)) CRAN dependencies, but keeping release at the GitHub repo and only uploading to CRAN at most once a month. Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. The new upstream release adds new more helper functions. Detailed changes in this release relative to the previous CRAN release are as follows:

Changes in RcppArmadillo version 0.7.400.2.0 (2016-08-24)

• Upgraded to Armadillo release 7.400.2 (Feral Winter Deluxe)
  • added expmat_sym(), logmat_sympd(), sqrtmat_sympd()
  • added .replace()

Changes in RcppArmadillo version 0.7.300.1.0 (2016-07-30)

• Upgraded to Armadillo release 7.300.1
  • added index_min() and index_max() standalone functions
  • expanded .subvec() to accept size() arguments
  • more robust handling of non-square matrices by lu()

Courtesy of CRANberries, there is a diffstat report. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

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

I read this tweet a couple of weeks ago:

to me, an inclusive security community would focus as much (or at all) on surveillance of women by abusive partners as it does the state kelsey ( ) (@_K_E_L_S_E_Y) August 2, 2016

and it got me thinking. Security research is often derided as unnecessary stunt hacking, proving insecurity in things that are sufficiently niche or in ways that involve sufficient effort that the realistic probability of any individual being targeted is near zero. Fixing these issues is basically defending you against nation states (who (a) probably don't care, and (b) will probably just find some other way) and, uh, security researchers (who (a) probably don't care, and (b) see (a)).

Unfortunately, this may be insufficient. As basically anyone who's spent any time anywhere near the security industry will testify, many security researchers are not the nicest people. Some of them will end up as abusive partners, and they'll have both the ability and desire to keep track of their partners and ex-partners. As designers and implementers, we owe it to these people to make software as secure as we can rather than assuming that a certain level of adversary is unstoppable. "Can a state-level actor break this" may be something we can legitimately write off. "Can a security expert continue reading their ex-partner's email" shouldn't be.

comments

Over the weekend I've played with continuous integration for Gammu to make it run on more platforms. I had to remember many things from the Windows world on the way and the solution is not yet complete, but the basic build is working, the only problematic part are external dependencies. First of all we already have Linux builds on Travis CI. These cover compilation with both GCC and Clang compilers, hopefully covering most of the possible problems. Recently I've added OS X builds on Travis CI, what was pretty much painless and worked out of the box. The next major architecture to support is Windows. Once I've discovered AppVeyor I thought it might be the way to go. The have free plans for open-source projects (though it has only one parallel build compared to four provided by Travis CI). As our build system is cross platform based on CMake, it should work pretty much out of the box, right? Well almost, tweaking the basics took some time (unfortunately there is no CMake support on AppVeyor, so you have to script it a bit). The most painful things on the way:

• finding our correct way to invoke build and testsuite
• our code was broken on Windows, making the testsuite to fail
• how to work with power shell (no, I'm not going to like it)
• how to download and install executable to PATH
• test output integration with AppVeyor - done using XSLT transformation and uploading test results manually
• 32-bit / 64-bit mess, CMake happily finds 32-bit libs during the 64-bit build and vice versa, what makes the build fail later when linking - fixed by trying if code can be built with given library
• 64-bit code crashes in dummy driver, causing testsuite failures (this has to be something Windows specific as the code works fine on 64-bit Linux) - this seems to be caused by too big allocations on stack, moving them to heap will fix this

You can check our current appveyor.yml in case you're going to try something similar. Current build results are on AppVeyor. As a nice side effect, we now have up to date Windows binaries for Gammu.

Filed under: Debian English Gammu 0 comments