The interest to participate in DebConf15, which will start in 10 days, has been overwhelming. Thank you so much! We planned the conference for 350 people and we now expect more than 570. This is fantastic and a wonderful support and encouragement for Debian and its contributors. But we are getting to the point where we have to prioritise considerations about the capacity of the venue and the safety of our attendees. We ve therefore had to close registrations until we have evaluated further options for accomodating even more attendees. For those of you who did not register for DebConf on time, but still want to participate, please bear with us and make sure to check back soon.

A new Armadillo release 5.300.4 was prepared by Conrad the other day, and we prepared a new corresponding RcppArmadillo release 0.5.300.4.0 which is now on CRAN and in way into Debian. 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. This release brings a considerable amount of new code extending support for sparse matrices, support for Schur decompositions, and much more as shown in the extract from NEWS file:

Changes in RcppArmadillo version 0.5.300.4 (2015-08-03)

• Upgraded to Armadillo 5.300.4 ("Plutocrazy Incorporated")
  • added generalised Schur decomposition: qz()
  • added .has_inf() and .has_nan()
  • expanded interp1() to handle out-of-domain locations
  • expanded sparse matrix class with .set_imag() and .set_real()
  • expanded imag(), real() and conj() to handle sparse matrices
  • expanded diagmat(), reshape() and resize() to handle sparse matrices
  • faster sparse sum()
  • faster row-wise sum(), mean(), min(), max()
  • updated physical constants to NIST 2014 CODATA values
  • fixes for handling sparse submatrix views
  • Armadillo can make use of GPUs by linking with NVIDIA NVBLAS (a GPU-accelerated implementation of BLAS), or by linking with AMD ACML (which can use GPUs via OpenCL)
• Added importFrom statements for R functions not from base
• Added explicit Rcpp::sourceCpp() reference as well
• Updated one formatting detail in vignette to please TeXlive2015

Courtesy of CRANberries, there is also a diffstat report for the most recent CRAN release. As always, 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.

In June I started keeping track of my Debian activities, and this is my July update. Elixir in Debian Elixir is a functional language built on top of the Erlang virtual machine. If features imutable data structures, interesting concurrency primitives, and everything else that Erlang does, but with a syntax inspired by Ruby what makes it much more aproachable in my opinion. Those interested in Elixir for Debian are encouraged to hang around in #debian-elixir on the OFTC IRC servers. There are still a lot of things to figure out, for example how packaging Elixir libraries and applications is going to work. MiniDebconf at FISL, and beyond I helped organize a MiniDebconf at this year s FISL, in Porto Alegre on the 10th of July. The whole program was targetted at getting more people to participate in Debian, so there were talks about translation, packaging, and a few other more specific topics. I myself gave two talks: one about Debian basics, What is Debian, and how it works , and second one on packaging the free software web , which I will also give at Debconf15 later this month. The recordings are available (all talks in Portuguese) at the Debian video archive thanks to Holger Levsen. We are also organizing a new MiniDebconf in October as part of the Latinoware schedule. Ruby We are in the middle of a transition to switch to Ruby 2.2 as default in Debian unstable, and we are almost there. The Ruby transition is now on hold while GCC 5 one is going on, but will be picked up as soon as were are done with GCC 5. ruby-defaults has been uploaded to experimental for those that want to try having Ruby 2.2 as default before that change hits unstable. I myself have been using Ruby 2.2 as default for several weeks without any problem so far, including using vagrant on a daily basis and doing all my development on sid with it. I started taking notes about Ruby interpreter transitions work to make sure that knowledge is registered. I have uploaded minor security updates of both ruby2.1 and ruby2.2 to unstable. They both reached testing earlier today. I have also fixed another bug in redmine, which I hope to get into stable as well as soon as possible. gem2deb has seen several improvements through versions 0.19, 0.20, 0.20.1 and 0.20.2. I have updated a few packages:

• ruby-rubymail
• ruby-ferret
• ruby-omniauth
• ruby-hashie
• ruby-rack-accept
• chef-zero
• nailgun-agent
• ruby-serialport
• ruby-gnome2
• ruby-mysql2
• ruby-dataobjects-postgres
• ruby-standalone
• thin
• ruby-stringex
• ruby-i18n

Two NEW packages, ruby-rack-contrib and ruby-grape-logging ,were ACCEPTED into the Debian archive. Kudos to the ftp-master team who are doing an awesome job reviewing new packages really fast. Debian Continuous Integration This month I have made good progress with the changes needed to make debci work as a distributed system with one master/scheduler node and as many worker nodes (running tests) as possible. While doing my tests, I have submitted a patch to lxc and updated autodep8 in unstable. At some point I plan to upload both autodep8 and autopkgtest to jessie-backports. Sponsoring I have sponsored a few packages:

• ruby-rack-mount, ruby-grape-entity, and ruby-grape for Hleb Valoshka.
• redir and tmate twice for Lucas Kanashiro.
• lxc to wheezy-backports for Christian Seiler.

The TODO group is an industry body that appears to be trying to define community best practices or something. I don't really know what their backstory is and whether they're trying to do meaningful work or just provide a fig leaf of respectability to organisations that dislike being criticised for doing nothing to improve the state of online communities but don't want to have to actually do anything, and their initial work on codes of conduct was, perhaps, suboptimal. But they do appear to be trying to improve things - this commit added a set of inappropriate behaviours, and also clarified that reverseisms were not actionable behaviour.

At which point Reddit lost its shit, because Reddit is garbage. And now the repository is a mess of white men attempting to explain how any policy that could allow them to be criticised is the real racism.

Fuck that shit.

Being a cis white man who's a native English speaker from a fairly well-off background, I'm pretty familiar with privilege. Spending my teenage years as an atheist of Irish Catholic upbringing in a Protestant school in a region of Northern Ireland that made parts of the bible belt look socially progressive, I'm also pretty familiar with the idea that that said privilege doesn't shield me from everything bad in life. Having privilege isn't a guarantee that my life will be better, in the same way that avoiding smoking doesn't mean I won't die of lung cancer. But there's an association in both cases, one that's strong enough to alter the statistical likelihood in meaningful ways.

And that inherently affects discussions about race or gender or sexuality. The probability that I've been subject to systematic discrimination because of these traits is vanishingly small. In the communities this policy is intended to cover, I'm the default. It's very difficult for any minority to exercise power over me. "You're white, you wouldn't understand" isn't fundamentally about my colour, it's about the fact that my colour means I haven't been subject to society trying to make my life more difficult at every opportunity. A community that considers saying that to be racist is a community that will never change the default, a community that will never be able to empower people who didn't grow up with that privilege. A code of conduct that makes it clear that "reverse racism" isn't grounds for complaint makes it clear that certain conversations are legitimate and helps ensure we have the framework we need to gradually change that default, and as such is better than one that doesn't.

(comments disabled because I don't trust any of you)

comments

It's been a while since I talked about Ceilometer and its companions, so I thought I'd go ahead and write a bit about what's going on this side of OpenStack. I'm not going to cover new features and fancy stuff today, but rather a shallow overview of the new project processes we initiated. Ceilometer growing Ceilometer has grown a lot since that time when we started it 3 years ago. It has evolved from a system designed to fetch and store measurements, to a more complex system, with agents, alarms, events, databases, APIs, etc. All those features were needed and asked for by users and operators, but let's be honest, some of them should never have ended up in the Ceilometer code repository, especially not all at the same time. The reality is we picked a pragmatic approach due to the rigidity of the OpenStack Technical Committee in regards to new projects to become OpenStack integrated and, therefore, blessed projects. Ceilometer was actually the first project to be incubated and then integrated. We had to go through the very first issues of that process. Fortunately, now that time has passed, and all those constraints have been relaxed. To me, the OpenStack Foundation is turning into something that looks like the Apache Foundation, and there's, therefore, no need to tie technical solutions to political issues. Indeed, the Big Tent now allows much more flexibility to all of that. Back a year ago, we were afraid to bring Gnocchi into Ceilometer. Was the Technical Committee going to review the project? Was the project going to be in the scope of Ceilometer for the Technical Committee? Now we don't have to ask ourselves those questions, now that we have that freedom, it empowers us to actually do what we think is good in term of technical design without worrying too much about political issues.

Ceilometer development activity

Acknowledging Gnocchi The first step in this new process was to continue working on Gnocchi (a timeserie database and resource indexer designed to overcome historical Ceilometer storage issue) and to decide that it was not the right call to merge it into Ceilometer as some REST API v3, but that it was better to keep it standalone. We managed to get traction to Gnocchi, getting a few contributors and users. We're even seeing talks proposed to the next Tokyo Summit where people leverage Gnocchi, such as "Service of predictive analytics on cost and performance in OpenStack", "Suveil" and "Cutting Edge NFV On OpenStack: Healing and Scaling Distributed Applications". We are also doing some progress on pushing Gnocchi outside of the OpenStack community, as it can be a self-sufficient timeserie and resource database that can be used without any OpenStack interaction. Branching Aodh Rather than continuing to grow Ceilometer, during the last summit we all decided that it was time to reorganize and split Ceilometer into the different components it is made of, leveraging a more service-oriented architecture. The alarm subsystem of Ceilometer being mostly untied to the rest of Ceilometer, we decided it was the first and perfect candidate to do that. I personally engaged into doing the work and created a new repository with only the alarm code from Ceilometer, named Aodh.

Aodh is an Irish word meaning fire. A word picked so it also had some relation to Heat, and because we have some Irish influence around the project .

This made sense for a lot of reason. First because Aodh can now work completely standalone, using either Ceilometer or Gnocchi as a backend or any new plugin you'd write. I love the idea that OpenStack projects can work standalone like Swift does for example without implying any other OpenStack component. I think it's a proof of good design. Secondly, because it allows us to resonate on a smaller chunk of software a reason really under-estimated today in OpenStack. I believe that the size of your software should match a certain ratio to the size of your team. Aodh is, therefore, a new project under the OpenStack Telemetry program (or what remains of OpenStack programs now), alongside Ceilometer and Gnocchi, forked from the original Ceilometer alarm feature. We'll deprecate the latter with the Liberty release, and we'll remove it in the Mitaka release. Lessons learned Actually, moving that code out of Ceilometer (in the case of Aodh), or not merging it in (in the case of Gnocchi) had a few side effects that I admit I think we probably under-estimated back then. Indeed, the code size of Gnocchi or Aodh ended up being much smaller than the entire Ceilometer project Gnocchi is 7 smaller and Aodh 5x smaller than Ceilometer and therefore much more easy to manipulate and to hack on. That allowed us to merge dozens of patches in a few weeks, cleaning-up and enhancing a lot of small things in the code. Those tasks are very much harder in Ceilometer, due to the bigger size of the code base and the small size of our team. By having our small team working on smaller chunks of changes even when it meant actually doing more reviews greatly improved our general velocity and the number of bugs fixed and features implemented. On the more sociological side, I think it gave the team the sensation of finally owning the project. Ceilometer was huge, and it was impossible for people to know every side of it. Now, it's getting possible for people inside a team to cover a much larger portion of those smaller project, which gives them a greater sense of ownership and caring. Which ends up being good for the project quality overall. That also means that we technically decided to have different core teams by project (Ceilometer, Gnocchi, and Aodh) as they all serve different purposes and can all be used standalone or with each others. Meaning we could have contributors completely ignoring other projects. All of that reminds me some discussion I heard about projects such as Glance, trying to fit new features in - some that are really orthogonal to the original purpose. It's now clear to me that having different small components interacting together that can be completely owned and taken care of by a (small) team of contributors is the way to go. People that can therefore trust each others and easily bring new people in, makes a project really incredibly more powerful. Having a project covering a too wide set of features make things more difficult if you don't have enough manpower. This is clearly an issue that big projects inside OpenStack are facing now, such as Neutron or Nova.

The last Whiteboard Wednesday tackled a few of the gotchas of the F5 CMP implementation. I take that as an opportunity to finish a blog post I started to write six month ago on this topic. I've run into two scenarios where CMP got in my way:

• Enforcing strict connection limits, especially with very low numbers of connections.
• Application health checks and the time you've to take into account until you receive no new connections to a pool node.

All of this happened on TMOS 11.4.1+HF run on BigIP 2K systems. Since F5 is sometimes moving very quickly you might not experience those issues on other hardware or with a different software release. applying low and strict connection limits Apparently connection limits are counted on a per tmm level and are not shared between the tmm processes running on different CPUs. So if you've two CPU cores with HT you'll see four tmm processes that will all enforce the connection limit. If you have a max connection limit set to two you might still see a maximum of eight connections. That is a very bad thing if you abuse the F5 to limit your outbound connections because your counter part is not able to enforce connection limits, but forces you via a contract to not open more then two connections. Disable CMP and it will all end on the same tmm process and suddenly your connection limits work as expected. If your connection limit is big enough you can cheat, say it's twelve connections, you can configure a limit of three. With four processes that makes a max of twelve connections as required. Though due to the hashing and distribution among the tmm processes it could happen that you reject connections on one process while others are idle. Another option would be to enter the dirty land of iRules and tables to maintain your own connection count table. There are examples given in the F5 devcentral community, but the best resolution you can get, without starting to scan the whole table on every request, is X requests per minute. active health checks Active monitoring checks were added to detect the operational state of our application servers. Now imagine you have some realtime processing with over a hundred requests per minute. So in case you've issues with one instance you'd like to remove it from the pool rather sooner then later, which requires frequent checking. So here is a simple active http check:

defaults-from http-appmon
destination *:*
interval 9
recv "^HTTP/1\\.1 200 OK"
send "GET /mon/state HTTP/1.1\\r\\nHost: MON\\r\\nConnection: Close\\r\\n\\r\\n"
time-until-up 0
timeout 2
up-interval 1

(Configuration options are described here) With an up-interval of 1 second and a timeout of 2 seconds someone naive like me expected that a fatal issue like a crashed application would be detected within three seconds and no more requests should hit the application after second 3. That turned out to be slightly longer, at least 4s for this case, often longer. Also for a regular maintenance we had to instruct our scripts to flip the application monitor to unavailable and wait for interval X tmm process count + timeout + 1s + max allowed request duration. That is not an instant off. If you use tcpdump (on the F5 where it's patched to show you the tmm that received the request) to look at the health check traffic you'll notice that the tmm threads pass around the handle to do a health check. So my guess is the threads do only sync the health check state of the application when they're due to run the health check. Makes sense performance wise but if you operate with longer timeouts and bigger intervals you will definetly loose a notable amount of requests. Even in our low end case we already loose a notable amount of requests in 4s. While you could resent them you never know exactly if a request was already processed or not. So you have to ensure that somewhere else in your stack. One option is to disable CMP but I guess that's not an option for most people that are required to scale out to handle the load and not only for the sake of redundancy. If you're running the balancer only for the sake of redundancy the choice is easy. You find a hint on this kind of issue if you lookup the documentation for the inband monitor: Note: Systems with multiple tmm processes use a per-process number to calculate failures, depending on the specified load balancing method. That case is a bit different due to the nature of the monitor but points in the same direction. The actual check is executed by bigd according to this document, so I'm pretty sure I'm still missing some pieces of the picture. Just be warned that you've to really test your outage scenarios and you should double check it if you run a transaction based service that is sensitive to lost requests.

There are plenty of criticisms of docker, the system for building a container-based virtual machine running just a single application. I've read many of them have have consistently been either in agreement or at least amused. The most relevant criticism is about the basic approach of building single-application virtual machines. To understand this criticism, let's remember - in traditional application deployment there are at least three distinct jobs:

• Distrubtion developers - the team the integrates all the various packages available into a coherent and well-functioning system and, importantly, monitors the upstream of all the packages to ensure that security bugs are properly packaged and made easily available for installation. These people don't give a shit about your PHP parse error and don't really care if you can't figure out the command to create a new Postgres Database.
• System administrators - these are the people that ensure that the security updates provided by the distribution developers get installed on a regular basis and if something breaks during this process, they are the ones that fix it. They know how to create your new postgres database. They don't really care about your PHP parse error either, but may get roped in to tell you it's a PHP parse error.
• Application developers - these are the people that care about the PHP parse error. They also know how to create beautiful things that end users can interact with.

These three groups have lived in happy tension for years. Now we have containers. The problem with containers is that suddenly the system administrators are out entirely and the distribution developers' role may have been dramatically minimized or circumvented altogether. Meanwhile, the application developer is both liberated from any constraints imposed by either the system administrator or the distribution developers (hooray!) but is also sadled with the enormous responsibilities of these two roles - which may not be apparent to the application developer at first. I have practically no distribution developer experience and have considerable experience as a system administrator and an application developer. And, it took me months to sort through how to properly develop and deploy an application using docker in a way that I thought was responsible and secure. I started by learning about how docker wants you to deploy images - by downloading them from their shared regisry. As I mentioned, I have very little experience in the realm of distribution development, but I at least know enough about Debian to know that a lot of time and thought has gone into cryptographically verifying packages that I install, which apparently is not done at all with Docker images. Is that obvious to everyone using Docker?? Fortunately, you can work around this problem by creating your own base image which is trivially easy. So, now I build all images, from scratch, locally. That helps put Debian developers back into the mix. Next, I started looking at Docker Files that I could use to construct my images and discovered something else troubling. Take, for example, the official nginx Docker image. It is based on Debian Jessie (hooray - our distribution developers are in the mix!). However, it then proceeds to install nginx from the nginx repository, not the debian repository. Well, I guess if you are nginx you want to have full control, but still, the Debian developers version of nginx has been vetted to ensure it works with Debian Jessie, so you are really losing something here. So... my next break from Docker convention is to use all Debian packages in my Docker files. Once my images were built and my application was tested and running, I was done, right? Wrong. Well, I would have been done if I didn't care about upgrading my systems, backing up my data or running cron jobs. Remember those things? Those are things that distribution developers and system administrators have been perfecting for decades. And, they are not trivial. I then built a series of scripts to help alert me when a image I am using has updates (you can't just use cron-apt any more since cron isn't running in your container) and help me update the image and deploy it to all my applications (which involves restarting the application). Backing up data is a whole different can of worms - sometimes involving interacting with your container (if it's a database container, you have to launch a database dump) or simply copying files from the host, assuming you got the right Docker volume strategy (which took me days to fully understand). Lastly, I had to run a cron job from the host that then runs whatever commands are needed on each of my containers. This was complicated. In the end, was it worth it? Yes, I think so. However, not because it was simple, which seems to be the Docker mantra. I think it's worth it because I can run 100 instances of my application using significantly less resources than when I was using full virtualization and because I can more easily and flexibly adjust the resource allocation. However, check in with me in a year and I'll probably have a different opinion.

What happened in the reproducible builds effort this week: Toolchain fixes

• Joachim Breitner uploaded haskell-devscripts/0.9.11 which ads support for UTF-8 encoded debian/control file with all locales. Original patch by Chris Lamb.
• Jonas Smedegaard uploaded ghostscript which adds support for SOURCE_DATE_EPOCH. Original patch by Dhole.

akira submitted a patch to make cdbs export SOURCE_DATE_EPOCH. She uploded a package with the enhancement to the experimental reproducible repository. Packages fixed The following 15 packages became reproducible due to changes in their build dependencies: dracut, editorconfig-core, elasticsearch, fish, libftdi1, liblouisxml, mk-configure, nanoc, octave-bim, octave-data-smoothing, octave-financial, octave-ga, octave-missing-functions, octave-secs1d, octave-splines, valgrind. The following packages became reproducible after getting fixed:

• ant-contrib/1.0~b3+svn177-7 by Emmanuel Bourg.
• authbind/2.1.1+nmu1 uploaded by Johannes Schauer, original patch by akira.
• elektra/0.8.12-1 uploaded by Pino Toscano, original patch by akira.
• glance/2015.1.0-3 by Thomas Goirand.
• gnumeric/1.12.23-1 uploaded by Dmitry Smirnov, original patch by Daniel Kahn Gillmor.
• libdevice-cdio-perl/0.3.0-5 uploaded by gregor herrmann, report by Chris Lamb.
• libxray-scattering-perl/3.0.1-1.1 uploaded by gregor herrmann, original patch by Reiner Herrmann.
• libxray-spacegroup-perl/0.1.1-2.1 uploaded by gregor herrmann, original patch by Chris Lamb.
• ryu/3.23-2 by Dariusz Dwornikowski.

Some uploads fixed some reproducibility issues but not all of them:

• apophenia/0.999e+ds-1 uploaded by Jerome Benoit, original patch by akira.
• xbs/0-10 uploaded by Matthew Vernon, original patch by Colin Watson.
• bbswitch/0.8-2 uploaded by Vincent Cheng, original patch by Chris Lamb.
• mariadb-10.0/10.0.20-3 by Otto Kek l inen.
• icedove/38.0.1-1 uploaded by Christoph Goehre, improvements by Carsten Schoenert.
• apache2/2.4.16-1 uploaded by Stefan Fritsch, improvements by Jean-Michel Vourg re.

In contrib, Dmitry Smirnov improved libdvd-pkg with 1.3.99-1-1. Patches submitted which have not made their way to the archive yet:

• #793705 on mime-support by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793922 on polymake by Chris Lamb: sort Perl hash keys.
• #793980 on lsof by Valentin Lorentz: removes extra informations from the build system..
• #793996 on at by Valentin Lorentz: use absolute values for chmod.
• #794005 on python-dtcwt by Chris Lamb: use a constant seed for the random number generator.
• #794011 on gzip by Valentin Lorentz: remove date from texinfo header.
• #794014 on moin by Dhole: normalizes the timezone and fixes timestamps from the files compressed with zip.
• #794106 on cryptsetup by Valentin Lorentz: use date from latest debian/changelog entry in manpage.
• #794130 on coq by Valentin Lorentz: use C locale and UTC timezone when generating the build date.
• #794225 on libsyncml by akira: export SOURCE_DATE_EPOCH.
• #794239 on zipios++ by akira: export SOURCE_DATE_EPOCH.
• #794247 on whizzytex by Dhole: remove current date from documentation.
• #794248 on cortado by Dhole: allow the build date to be set externally and use time from the latest debian/changelog entry.
• #794395 on classified-ads by Reiner Herrmann: remove timestamps from PNG images.
• #794398 on clhep by Reiner Herrmann: sort source file list.
• #794399 on parsec47 by Reiner Herrmann: use C locale when sorting source files.
• #794400 on tumiki-fighters by Reiner Herrmann: use C locale when sorting source files.

reproducible.debian.net Four armhf build hosts were provided by Vagrant Cascadian and have been configured to be used by jenkins.debian.net. Work on including armhf builds in the reproducible.debian.net webpages has begun. So far the repository comparison page just shows us which armhf binary packages are currently missing in our repo. (h01ger) The scheduler has been changed to re-schedule more packages from stretch than sid, as the gcc5 transition has started This mostly affects build log age. (h01ger) A new depwait status has been introduced for packages which can't be built because of missing build dependencies. (Mattia Rizzolo) debbindiff development Finally, on August 31st, Lunar released debbindiff 27 containing a complete overhaul of the code for the comparison stage. The new architecture is more versatile and extensible while minimizing code duplication. libarchive is now used to handle cpio archives and iso9660 images through the newly packaged python-libarchive-c. This should also help support a couple other archive formats in the future. Symlinks and devices are now properly compared. Text files are compared as Unicode after being decoded, and encoding differences are reported. Support for Sqlite3 and Mono/.NET executables has been added. Thanks to Valentin Lorentz, the test suite should now run on more systems. A small defiency in unquashfs has been identified in the process. A long standing optimization is now performed on Debian package: based on the content of the md5sums control file, we skip comparing files with matching hashes. This makes debbindiff usable on packages with many files. Fuzzy-matching is now performed for files in the same container (like a tarball) to handle renames. Also, for Debian .changes, listed files are now compared without looking the embedded version number. This makes debbindiff a lot more useful when comparing different versions of the same package. Based on the rearchitecturing work has been done to allow parallel processing. The branch now seems to work most of the time. More test needs to be done before it can be merged. The current fuzzy-matching algorithm, ssdeep, has showed disappointing results. One important use case is being able to properly compare debug symbols. Their path is made using the Build ID. As this identifier is made with a checksum of the binary content, finding things like CPP macros is much easier when a diff of the debug symbols is available. Good news is that TLSH, another fuzzy-matching algorithm, has been tested with much better results. A package is waiting in NEW and the code is ready for it to become available. A follow-up release 28 was made on August 2nd fixing content label used for gzip2, bzip2 and xz files and an error on text files only differing in their encoding. It also contains a small code improvement on how comments on Difference object are handled. This is the last release name debbindiff. A new name has been chosen to better reflect that it is not a Debian specific tool. Stay tuned! Documentation update Valentin Lorentz updated the patch submission template to suggest to write the kind of issue in the bug subject. Small progress have been made on the Reproducible Builds HOWTO while preparing the related CCCamp15 talk. Package reviews 235 obsolete reviews have been removed, 47 added and 113 updated this week. 42 reports for packages failing to build from source have been made by Chris West (Faux). New issue added this week: haskell_devscripts_locale_substvars. Misc. Valentin Lorentz wrote a script to report packages tested as unreproducible installed on a system. We encourage everyone to run it on their systems and give feedback!

This is the entire complaint that was received:

We are an IT security company from Spain. We have detected sensitive information belonging to Banesco Banco Universal, C.A. clientes. As authorized representative in the resolution of IT security incidents affecting Banesco Banco Universal, C.A., we demand the deletion of the content related to Banesco Banco Universal, C.A, clients. This content violates the law about electronic crime in Venezuela (see Ley Especial sobre Delitos Inform ticos de Venezuela , Chapter III, Articles 20 y 23).

Note the complete lack of any information regarding what URLs, or even which site(s), they consider to be problematic. Nope, just delete all our stuff! and a wave of the against the law somewhere! stick.

Follow me on Identi.ca or Twitter or Diaspora* Here are the details of my Free activities in July 2015. Carl Chenet s projects:

• Retweet version 0.1 Github home page
  • a small project of Twitter bot for le Journal du hacker small and efficient. Github star it if you like it ;)
• Le Journal du hacker wip almost complete the full localization into French
  • Localization of le Journal du hacker was not fully completed. It should be 99% after these changes.

Patchs:

• planet.sysadmin-fr.org pull request to add Carl Chenet s blog #5
  • Carl Chenet s blog is now on planet.sysadmin-fr.org, which is an aggregator for french-speaking sysadmins. You should git it a try!

Debian bug reports:

• Docker.io Manual page for the docker-compose executable is missing #792518
• Docker.io New Docker version 1.7.1 available #793483
• Backupchecker now available in Debian Stretch (Testing) Backupchecker migration log report

Other bug reports:

• Docker-compose A manual page for docker-compose #1727
• feedDiasp Failed to login: NoneType object has no attribute group #6
• rss-bot-diasp feedDiasp.feedDiasp.Diasp.LoginException: NoneType object has no attribute group #1

Feature requests:

• Weboob SFR mobile phone Invoices in sfr module #2045

It s Seafair weekend in Seattle. As always, the centerpiece is the H1 Unlimited hydroplane races on Lake Washington. In my social circle, I m nearly the only person I know who grew up in area. None of the newcomers I know had heard of hydroplane racing before moving to Seattle. Even after I explain it to them i.e., boats with 3,000+ horse power airplane engines that fly just above the water at more than 320kph (200mph) leaving 10m+ (30ft) wakes behind them! most people seem more puzzled than interested. I grew up near the shore of Lake Washington and could see (and hear!) the races from my house. I don t follow hydroplane racing throughout the year but I do enjoy watching the races at Seafair. Here s my attempt to explain and make the case for the races to new Seattleites. Before Microsoft, Amazon, Starbucks, etc., there were basically three major Seattle industries: (1) logging and lumber based industries like paper manufacturing; (2) maritime industries like fishing, shipbuilding, shipping, and the navy; (3) aerospace (i.e., Boeing). Vintage hydroplane racing represented the Seattle trifecta: Wooden boats with airplane engines! The wooden U-60 Miss Thriftway circa 1955 (Thriftway is a Washinton-based supermarket that nobody outside has heard of) below is a picture of old-Seattle awesomeness. Modern hydroplanes are now made of fiberglass but two out of three isn t bad. Although the boats are racing this year in events in Indiana, San Diego, and Detroit in addition to the two races in Washington, hydroplane racing retains deep ties to the region. Most of the drivers are from the Seattle area. Many or most of the teams and boats are based in Washington throughout the year. Many of the sponsors are unknown outside of the state. This parochialness itself cultivates a certain kind of appeal among locals. In addition to old-Seattle/new-Seattle cultural divide, there s a class divide that I think is also worth challenging. Although the demographics of hydro-racing fans is surprisingly broad, it can seem like Formula One or NASCAR on the water. It seems safe to suggest that many of the demographic groups moving to Seattle for jobs in the tech industry are not big into motorsports. Although I m no follower of motorsports in general, I ve written before cultivated disinterest in professional sports, and it remains something that I believe is worth taking on. It s not all great. In particular, the close relationship between Seafair and the military makes me very uneasy. That said, even with the military-heavy airshow, I enjoy the way that Seafair weekend provides a little pocket of old-Seattle that remains effectively unchanged from when I was a kid. I d encourage others to enjoy it as well!

It s Seafair weekend in Seattle. As always, the centerpiece is the H1 Unlimited hydroplane races on Lake Washington. In my social circle, I m nearly the only person I know who grew up in area. None of the newcomers I know had heard of hydroplane racing before moving to Seattle. Even after I explain it to them i.e., boats with 3,000+ horse power airplane engines that fly just above the water at more than 320kph (200mph) leaving 10m+ (30ft) wakes behind them! most people seem more puzzled than interested. I grew up near the shore of Lake Washington and could see (and hear!) the races from my house. I don t follow hydroplane racing throughout the year but I do enjoy watching the races at Seafair. Here s my attempt to explain and make the case for the races to new Seattleites. Before Microsoft, Amazon, Starbucks, etc., there were basically three major Seattle industries: (1) logging and lumber based industries like paper manufacturing; (2) maritime industries like fishing, shipbuilding, shipping, and the navy; (3) aerospace (i.e., Boeing). Vintage hydroplane racing represented the Seattle trifecta: Wooden boats with airplane engines! The wooden U-60 Miss Thriftway circa 1955 (Thriftway is a Washinton-based supermarket that nobody outside has heard of) below is a picture of old-Seattle awesomeness. Modern hydroplanes are now made of fiberglass but two out of three isn t bad. Although the boats are racing this year in events in Indiana, San Diego, and Detroit in addition to the two races in Washington, hydroplane racing retains deep ties to the region. Most of the drivers are from the Seattle area. Many or most of the teams and boats are based in Washington throughout the year. Many of the sponsors are unknown outside of the state. This parochialness itself cultivates a certain kind of appeal among locals. In addition to old-Seattle/new-Seattle cultural divide, there s a class divide that I think is also worth challenging. Although the demographics of hydro-racing fans is surprisingly broad, it can seem like Formula One or NASCAR on the water. It seems safe to suggest that many of the demographic groups moving to Seattle for jobs in the tech industry are not big into motorsports. Although I m no follower of motorsports in general, I ve written before cultivated disinterest in professional sports, and it remains something that I believe is worth taking on. It s not all great. In particular, the close relationship between Seafair and the military makes me very uneasy. That said, even with the military-heavy airshow, I enjoy the way that Seafair weekend provides a little pocket of old-Seattle that remains effectively unchanged from when I was a kid. I d encourage others to enjoy it as well!

The list of available wifi channels is slightly different from country to country. To ensure access to the right channels and transmit power settings, one needs to set the right regulatory domain in the wifi stack.

Linux For most Linux-based computers, you can look and change the current regulatory domain using these commands:

iw reg get
iw reg set CA

where CA is the two-letter country code when the device is located. On Debian and Ubuntu, you can make this setting permanent by putting the country code in /etc/default/crda. Finally, to see the list of channels that are available in the current config, use:

iwlist wlan0 frequency

OpenWRT On OpenWRT-based routers (including derivatives like Gargoyle), looking and setting the regulatory domain temporarily works the same way (i.e. the iw commands above). In order to persist your changes though, you need to use the uci command:

uci set wireless.radio0.country=CA
uci set wireless.radio1.country=CA
uci commit wireless

where wireless.radio0 and wireless.radio1 are the wireless devices specific to your router. You can look them up using:

uci show wireless

To test that it worked, simply reboot the router and then look at the selected regulatory domain:

iw reg get

Scanning the local wifi environment Once your devices are set to the right country, you should scan the local environment to pick the least congested wifi channel. You can use the Kismet spectools (free software) if you have the hardware, otherwise WifiAnalyzer (proprietary) is a good choice on Android (remember to manually set the available channels in the settings).

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. Debian LTS This month I have been paid to work 15 hours on Debian LTS. In that time I did the following:

• Finished the work on tracker.debian.org to make it display detailed security status on each supported release (example).
• Prepared and released DLA-261-2 fixing a regression in the aptdaemon security update (happening only when you have python 2.5 installed).
• Prepared and released DLA-272-1 fixing 3 CVE in python-django.
• Prepared and released DLA-286-1 fixing 1 CVE in squid3. The patch was rather hard to backport. Thankfully upstream was very helpful, he reviewed and tested my patch.
• Did one week of LTS Frontdesk with CVE triaging. I pushed 19 commits to the security tracker.

Kali Linux / Debian Stretch work Kali Linux wants to experiment something close to Debian Constantly Usable Testing: we have a kali-rolling release that is based on Debian Testing and we want to take a new snapshot every 4 months (in order to have 3 releases per year). More specifically we have a kali-dev repository which is exactly Debian Stretch + our own Kali packages (the kali package take precedence) updated 4 times a day, just like testing is. And we have a britney2 setup that generates kali-rolling out of kali-dev (without any requirement in terms of delay/RC bugs, it just ensures that dependencies are not broken), also 4 times a day. We have jenkins job that ensures that our metapackages are installable in kali-dev (and kali-rolling) and that we can build our ISO images. When things break, I have to fix them and I try to fix them on the Debian side first. So here are some examples of stuff I did in response to various failures:

• Reported #791588 on texinfo. It was missing a versioned dependency on tex-common and migrated too early. The package was uninstallable in testing for a few days.
• Reported #791591 on pinba-engine-mysql-5.5: package was uninstallable (had to be rebuilt). It appeared on output files of our britney instance.
• I made a non-maintainer upload (NMU) of chkrootkit to fix two RC bugs so that the package can go back to testing. The package is installed by our metapackages.
• Reported #791647: debtags no longer supports debtags update local (a feature that went away but that is used by Kali).
• I made a NMU of debtags to fix a release critical bug (#791561 debtags: Missing dependency on python3-apt and python3-debian). kali-debtags was uninstallable because it calls debtags in its postinst.
• Reported #791874 on python-guess-language: Please add a python 2 library package. We have that package in Kali and when I tried to sync it from Debian I broke something else in Kali which depends on the Python 2 version of the package.
• I made a NMU of tcpick to fix a build failure with GCC5 so that the package could go back to testing (it s part of our metapackages).
• I requested a bin-NMU of jemalloc and a give-back of hiredis on powerpc in #792246 to fix #788591 (hiredis build failure on powerpc). I also downgraded the severity of #784768 to important so that the package could go back to testing. Hiredis is a dependency of OpenVAS and we need the package in testing.

If you analyze this list, you will see that a large part of the issues we had come down to package getting removed from testing due to RC bugs. We should be able to anticipate those issues and monitor the packages that have an impact on Kali. We will probably add new jenkins job that installs all the metapackages and then run how-can-i-help -s testing-autorm --old I just submitted #794238 as a wishlist against how-can-i-help. At the same time, there are bugs that make it into testing and that I fix / work around on the Kali side. But those fixes / work around might be more useful if they were pushed to testing via testing-proposed-updates. I tried to see whether other derivatives had similar needs to see if derivatives could join their efforts at this level but it does not look like so for now. Last but not least, bugs reported on the Kali side also resulted in Debian improvements:

• I reported #793360 on apt: APT::Never-MarkAuto-Sections not working as advertised. And I submitted a patch.
• I orphaned dnswalk and made a QA upload to fix its only bug.
• We wanted a newer version of the nvidia drivers. I filed #793079 requesting the new upstream release and the maintainer quickly uploaded it to experimental. I imported it on the Kali side but discovered that it was not working on i386 so I submitted #793160 with a patch.
• I noticed that Kali build daemons tend to accumulate many /dev/shm mounts and tracked this down to schroot. I reported it as #793081.

Other Debian work Sponsorship. I sponsored multiple packages for Daniel Stender who is packaging prospector, a software that I requested earlier (through RFP bug). So I reviewed and uploaded python-requirements-detector, python-setoptconf, pylint-celery and pylint-common. During a review I also discovered a nice bug in dh-python (#793609a comment in the middle of a Build-Depends could break a package). I also sponsored an upload of notmuch-addrlookup (new package requested by a Freexian customer). Packaging. I uploaded python-django 1.7.9 in unstable and 1.8.3 in experimental to fix security issues. I uploaded a new upstream release of ditaa through a non-maintainer uploaded (again at the request of a Freexian customer). Distro Tracker. Beside the work to integrate detailed security status, I fixed the code to be compatible with Django 1.8 and modified the tox configuration to ensure that the test suite is regularly run against Django 1.8. I also merged multiple patches of Christophe Siraut (cf #784151 and #754413). Thanks See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

The DUCK challenge is making a quite stable progress: in the last 4 weeks there were approximately 12.25 packages fixed and uploaded per week. In the current week the following packages were fixed and uploaded into unstable:

• Fran ois-Ren Ridea uploaded cl-adsl
• gregor herrmann uploaded libdevel-profile-perl and libmail-verp-perl
• Lucas Kanashiro uploaded libclass-singleton-perl, libpod-readme-perl and libconfig-json-perl
• Jordi Mallach uploaded fcgiwrap
• Joao Eriberto Mota Filho uploaded rifiuti and rifiuti2
• Gergely Nagy uploaded dh-exec
• Ian Jackson uploaded dgit
• Rapha l Hertzog uploaded memdump
• Joao Eriberto Mota Filho uploaded recoverdm
• Picca Fr d ric-Emmanu uploaded sardana

So we had 14 packages fixed and uploaded by 10 different uploaders. A big "Thank You" to you!! Since the start of this challenge, a total of 49 packages, uploaded by 31 different persons were fixed. Here is a quick overview:

	Week 1	Week 2	Week 3	Week 4	Week 5	Week 6	Week 7
# Packages	10	15	10	14	-	-	-
Total	10	25	35	49	-	-	-

The list of the fixed and updated packages is availabe here. I will try to update this ~daily. If I missed one of your uploads, please drop me a line. DebConf15 is approaching quite fast, so please get involved: The DUCK Challenge is running until end of DebConf15! Pevious articles are here: Week 1, Week 2, Week 3.

So we're in Finland, and the differences start out immediately. We're renting a flat, in building ten, on a street. You'd think "10 Streetname" was a single building, but no. It is a pair of buildings: 10A, and 10B. Both of the buildings have 12 flats in them, with 10A having 1-12, and 10B having 13-24. There's a keypad at the main entrance, which I assumed was to let you press a button and talk to the people inside "Hello I'm the postmaster", but no. There is no intercom system, instead you type in a magic number and the door opens. The magic number? Sounds like you want to keep that secret, since it lets people into the common-area? No. Everybody has it. The postman, the cleaners, the DHL delivery man, and all the ex-tenants. We invited somebody over recently and gave it out in advance so that they could knock on our flat-door. Talking of cleaners: In the UK I lived in a flat and once a fortnight somebody would come and sweep the stair-well, since we didn't ever agree to do it ourselves. Here somebody turns up every day, be it to cut the grass, polish the hand-rail, clean the glass on the front-door, or mop the floors of the common area. Sounds awesome. But they cut the grass, right outside our window, at 7:30AM. On the dot. (Or use a leaf-blower, or something equally noisy.) All this communal-care is paid for by the building-association, of which all flat-owners own shares. Sounds like something we see in England, or even like Americas idea of a Home-Owners-Association. (In Scotland you own your own flat, you don't own shares of an entity which owns the complete building. I guess there are pros and cons to both approaches.) Moving onwards other things are often the same, but the differences when you spot them are odd. I'm struggling to think of them right now, somebody woke me up by cutting our grass for the second time this week (!) Anyway I'm registered now with the Finnish government, and have a citizen-number, which will be useful, I've got an appointment booked to register with the police - which is something I had to do as a foreigner within the first three months - and today I've got an appointment with a local bank so that I can have a euro-bank-account. Happily I did find a gym to join, the owner came over one Sunday to give me a tiny-tour, and then gave me a list of other gyms to try if his wasn't good enough - which was a nice touch - I joined a couple of days later, his gym is awesome. (I'm getting paid in UK-pounds, to a UK-bank, so right now I'm getting local money by transferring to my wifes account here, but I want to do that to my own, and open a shared account for paying for rent, electricity, internet, water, & etc). My flat back home is still not rented, because the nice property management company lost my keys. Yeah you can't make that up can you? With a bit of luck the second set of keys I mailed them will arrive soon and the damn thing can be occupied, while I'm not relying on that income I do wish to have it.

Hadley is a popular figure, and rightly so as he successfully introduced many newcomers to the wonders offered by R. His approach strikes some of us old greybeards as wrong---I particularly take exception with some of his writing which frequently portrays a particular approach as both the best and only one. Real programming, I think, is often a little more nuanced and aware of tradeoffs which need to be balanced. As a book on another language once popularized: "There is more than one way to do things." But let us leave this discussion for another time. As the reach of the Hadleyverse keeps spreading, we sometimes find ourselves at the receiving end of a cost/benefit tradeoff. That is what this post is about, and it uses a very concrete case I encountered yesterday. As blogged earlier, the RcppZiggurat package was updated. I had not touched it in a year, but Brian Ripley had sent a brief and detailed note concerning something flagged by the Solaris compiler (correctly suggesting I replace fabs() with abs() on integer types). (Allow me to stray from the main story line here for a second to stress just how insane a work load he is carrying, essentially for all of us. R and the R community are so just so indebted to him for all his work---which makes the usual social media banter about him so unfortunate. But that too shall be left for another time.) Upon making the simple fix, and submitting to GitHub the usual Travis CI was triggered. And here is what I saw:
All happy, all green. Previous build a year ago, most recent build yesterday, both passed. But hold on: test time went from 2:54 minutes to 7:47 minutes for an increase of almost five minutes! And I knew that I had not added any new dependencies, or altered any build options. What did happen was that among the dependencies of my package, one had decided to now also depend on ggplot2. Which leads to a chain of sixteen additional packages being loaded besides the four I depend upon---when it used to be just one. And that took five minutes as all those packages are installed from source, and some are big and take a long time to compile. There is however and easy alternative, and for that we have to praise Michael Rutter who looks after a number of things for R on Ubuntu. Among these are the R builds for Ubuntu but also the rrutter PPA as well as the c2d4u PPA. If you have not heard this alphabet soup before, a PPA is a package repository for Ubuntu where anyone (who wants to sign up) can upload (properly setup) source files which are then turned into Ubuntu binaries. With full dependency resolution and all other goodies we have come to expect from the Debian / Ubuntu universe. And Michael uses this facility with great skill and calm to provide us all with Ubuntu binaries for R itself (rebuilding what yours truly uploads into Debian), as well as a number of key packages available via the CRAN mirrors. Less know however is this "c2d4u" which stands for CRAN to Debian for Ubuntu. And this builds on something Charles Blundell once built under my mentorship in a Google Summer of Code. And Michael does a tremdous job covering well over a thousand CRAN source packages---and providing binaries for all. Which we can use for Travis! What all that means is that I could now replace the line

 - ./travis-tool.sh install_r RcppGSL rbenchmark microbenchmark highlight

which implies source builds of the four listed packages and all their dependencies with the following line implying binary installations of already built packages:

 - ./travis-tool.sh install_aptget libgsl0-dev r-cran-rcppgsl r-cran-rbenchmark r-cran-microbenchmark r-cran-highlight

In this particular case I also needed to build a binary package of my RcppGSL package as this one is not (yet) handled by Michael. I happen to have (re-)discovered the beauty of PPAs for Travis earlier this year and revitalized an older and largely dormant launchpad account I had for this PPA of mine. How to build a simple .deb package will also have to left for a future post to keep this more concise. This can be used with the existing r-travis setup---but one needs to use the older, initial variant in order to have the ability to install .deb packages. So in the .travis.yml of RcppZiggurat I just use

before_install:
## PPA for Rcpp and some other packages
- sudo add-apt-repository -y ppa:edd/misc
## r-travis by Craig Citro et al
- curl -OL http://raw.github.com/craigcitro/r-travis/master/scripts/travis-tool.sh
- chmod 755 ./travis-tool.sh
- ./travis-tool.sh bootstrap

to add my own PPA and all is good. If you do not have a PPA, or do not want to create your own packages you can still benefit from the PPAs by Michael and "mix and match" by installing from binary what is available, and from source what is not. Here we were able to use an all-binary approach, so let's see the resulting performance:
Now we are at 1:03 to 1:15 minutes---much better. So to conclude, while the every expanding universe of R packages is fantastic for us as users, it can be seen to be placing a burden on us as developers when installing and testing. Fortunately, the packaging infrastructure built on top of Debian / Ubuntu packages can help and dramatically reduce build (and hence test) times. Learning about PPAs can be a helpful complement to learning about Travis and continued integration. So maybe now I need a new reason to blame Hadley? Well, there is always snake case ...

Follow-up: The post got some pretty immediate feedback shortly after I posted it. Craig Citro pointed out (quite correctly) that I could use r_binary_install which would also install the Ubuntu binaries based on their R packages names. Having built R/CRAN packages for Debian for so long, I am simply more used to the r-cran-* notations, and I think I was also the one contributing install_aptget to r-travis ... Yihui Xie spoke up for the "new" Travis approach deploying containers, caching of packages and explicit whitelists. It was in that very (GH-based) discussion that I started to really lose faith in the new Travis approach as they want use to whitelist each and every package. With 6900 and counting at CRAN I fear this simply does not scale. But different approaches are certainly welcome. I posted my 1:03 to 1:15 minutes result. If the "New School" can do it faster, I'd be all ears.

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

this week, besides other activities, I again managed to NMU a few packages as part of the GCC 5 transition. & again I could build on patches submitted by various HP engineers & other helpful souls.

• #757525 hardinfo: "hardinfo: FTBFS with clang instead of gcc"
  patch to build with -std=gnu89, upload to DELAYED/5
• #758723 nagios-plugins-rabbitmq: "should depend on libjson-perl"
  add missing dependency, upload to DELAYED/5
• #777766 src:adun.app: "adun.app: ftbfs with GCC-5"
  send updated patch to BTS
• #777837 src:ebview: "ebview: ftbfs with GCC-5"
  add patch from paulownia@Safe-mail.net, upload to DELAYED/5
• #777882 src:gnokii: "gnokii: ftbfs with GCC-5"
  build with -fgnu89-inline, upload to DELAYED/5
• #777907 src:hunt: "hunt: ftbfs with GCC-5"
  apply patch from Nicholas Luedtke, upload to DELAYED/5
• #777920 src:isdnutils: "isdnutils: ftbfs with GCC-5"
  add patch to build with -fgnu89-inline; upload to DELAYED/5
• #778019 src:multimon: "multimon: ftbfs with GCC-5"
  build with -fgnu89-inline; upload to DELAYED/5
• #778068 src:pork: "pork: ftbfs with GCC-5"
  build with -fgnu89-inline, QA upload
• #778098 src:quarry: "quarry: ftbfs with GCC-5"
  build with -std=gnu89, upload to DELAYED/5, then rescheduled to 0-day with maintainer's permission
• #778099 src:ratbox-services: "ratbox-services: ftbfs with GCC-5"
  build with -fgnu89-inline, upload to DELAYED/5, later cancelled because package is about to be removed (#793408)
• #778109 src:s51dude: "s51dude: ftbfs with GCC-5"
  build with -fgnu89-inline, upload to DELAYED/5
• #778116 src:shell-fm: "shell-fm: ftbfs with GCC-5"
  apply patch from Brett Johnson, upload to DELAYED/5
• #778119 src:simulavr: "simulavr: ftbfs with GCC-5"
  apply patch from Brett Johnson, QA upload
• #778120 src:sipsak: "sipsak: ftbfs with GCC-5"
  apply patch from Brett Johnson, upload to DELAYED/5
• #778122 src:skyeye: "skyeye: ftbfs with GCC-5"
  build with -fgnu89-inline, QA upload
• #778140 src:tcpcopy: "tcpcopy: ftbfs with GCC-5"
  add patch backported from upstream git, upload to DELAYED/5
• #778145 src:thewidgetfactory: "thewidgetfactory: ftbfs with GCC-5"
  add missing #include, upload to DELAYED/5
• #778164 src:vtun: "vtun: ftbfs with GCC-5"
  add patch from Tim Potter, upload to DELAYED/5
• #790464 flow-tools: "Please drop conditional build-depend on libmysqlclient15-dev"
  drop obsolete dependency, NMU
• #793336 src:libdevel-profile-perl: "libdevel-profile-perl: FTBFS with perl 5.22 in experimental (MakeMaker changes)"
  finish and upload package modernized by XTaran (pkg-perl)
• #793580 libb-hooks-parser-perl: "libb-hooks-parser-perl: B::Hooks::Parser::Install::Files missing"
  investigate and forward upstream, upload new upstream release later (pkg-perl)

What happened in the reproducible builds effort this week: Toolchain fixes

• Emmanuel Bourg uploaded maven-archiver/2.6-3 which fixed parsing DEB_CHANGELOG_DATETIME with non English locales.
• Emmanuel Bourg uploaded maven-repo-helper/1.8.12 which always use the same system independent encoding when transforming the pom files.
• Piotr O arowski uploaded dh-python/2.20150719 which makes the order of the generated maintainer scripts deterministic. Original patch by Chris Lamb.

akira uploaded a new version of doxygen in the experimental reproducible repository incorporating upstream patch for SOURCE_DATE_EPOCH, and now producing timezone independent timestamps. Dhole updated Peter De Wachter's patch on ghostscript to use SOURCE_DATE_EPOCH and use UTC as a timezone. A modified package is now being experimented. Packages fixed The following 14 packages became reproducible due to changes in their build dependencies: bino, cfengine2, fwknop, gnome-software, jnr-constants, libextractor, libgtop2, maven-compiler-plugin, mk-configure, nanoc, octave-splines, octave-symbolic, riece, vdr-plugin-infosatepg. The following packages became reproducible after getting fixed:

• cpl-plugin-fors/5.0.11+dfsg-4 uploaded by Ole Streicher, original patch by Chris Lamb.
• cpl-plugin-hawki/1.8.18+dfsg-4 uploaded by Ole Streicher, original patch by Chris Lamb.
• cpl-plugin-kmos/1.3.12+dfsg-4 uploaded by Ole Streicher, original patch by Chris Lamb.
• cpl-plugin-visir/3.5.1+dfsg-3 uploaded by Ole Streicher, original patch by Chris Lamb.
• docbook-dsssl/1.79-8 uploaded by Peter Eisentraut, original patch by Chris Lamb.
• git-annex/5.20150617 by Joey Hess, initial report by Daniel Kahn Gillmor.
• links2/2.10-1 by Axel Beckert.
• linuxlogo/5.11-8 uploaded by Dariusz Dwornikowski, original patch by Reiner Herrmann.
• maradns/2.0.11-1 uploaded by Dariusz Dwornikowski, original patch by Reiner Herrmann.
• pkgconf/0.9.12-1 uploaded by Andrew Shadura, original patch by Juan Picca.
• python-odf/1.3.1+dfsg-1 uploaded by W. Martin Borgert, original patch by akira.
• qsapecng/2.0.0-6 uploaded by Simone Rossetto, original patch by akira.
• ruby-liquid/3.0.4-1 uploaded by C dric Boutillier, report by Dylan Thacker-Smith.
• ruby-standalone/0.5.1 uploaded by Antonio Terceiro, original patch by Reiner Herrmann.
• sahara/2015.1.0-6 uploaded by Thomas Goirand, original patch by Juan Picca.
• squid3/3.5.6-1 uploaded by Luigi Gangitano, fixed upstream.
• tabble/0.43-3 uploaded by gregor herrmann, original patch by Reiner Herrmann.
• twine/1.5.0-1 by Zygmunt Krynicki.
• visp/2.10.0-4 uploaded by Fabien Spindler, original patch by akira.

Some uploads fixed some reproducibility issues but not all of them:

• dpatch/2.0.36 by Gergely Nagy, with a patch from akira.
• fldigi/3.22.13-1 by Kamal Mostafa.
• fortunes-bg/1.2 uploaded by Anton Zinoviev, original patch by akira.
• openjfx/8u40-b25-3 by Emmanuel Bourg.
• zoneminder/1.28.1-7 by Dmitry Smirnov.
• zookeeper/3.4.6-5 by Emmanuel Bourg.

Patches submitted which have not made their way to the archive yet:

• #792943 on argus-client by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792945 on authbind by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792947 on cvs-mailcommit by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792949 on chimera2 by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792950 on ccze by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792951 on dbview by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792952 on dhcpdump by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792953 on dhcping by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792955 on dput by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792958 on dtaus by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792959 on elida by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792961 on enemies-of-carlotta by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792963 on erc by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792965 on fastforward by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792967 on fgetty by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792969 on flowscan by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792971 on junior-doc by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792972 on libjama by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792973 on liblip by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792974 on liblockfile by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792975 on libmsv by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792976 on logapp by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792977 on luakit by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792978 on nec by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792979 on runit by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792980 on tworld by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792981 on wmweather by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792982 on ftpcopy by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792983 on gerstensaft by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792984 on integrit by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792985 on ipsvd by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792986 on uruk by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792987 on jargon by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792988 on xbs by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792989 on freecdb by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792990 on skalibs by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792991 on gpsmanshp by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792993 on cgoban by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792994 on angband-doc by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792995 on abook by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792996 on bcron by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792998 on chiark-utils by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792999 on console-cyrillic by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793000 on beav by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793001 on blosxom by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793002 on cgilib by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793003 on daemontools by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793004 on debdelta by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793005 on checkpw by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793006 on dropbear by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793126 on torbutton by Dhole: set TZ=UTC when calling zip.
• #793127 on pdf.js by Dhole: set TZ=UTC when calling zip.
• #793300 on deejayd by Dhole: set TZ=UTC when calling zip.

reproducible.debian.net Packages identified as failing to build from source with no bugs filed and older than 10 days are scheduled more often now (except in experimental). (h01ger) Package reviews 178 obsolete reviews have been removed, 59 added and 122 updated this week. New issue identified this week: random_order_in_ruby_rdoc_indices. 18 new bugs for packages failing to build from sources have been reported by Chris West (Faux), and h01ger.