FLOSS Project Planets

Last week in Kube

Planet KDE - Thu, 2017-12-07 07:50

We’re now running a Kube program with Kolab Now where you can get a basic Kolab Now account now, and see it’s features grow together with Kube, while the price remains the same. To take advantage of that offer, install the Kolab Now flatpak and signup through Kube.

  • Fixed a problem where emails with a header larger than 8kb would not be parsed correctly.
  • Added a Kolab Now signup capability to the Kolab Now settings.
  • Added merging of log entries of the same type so you don’t end up with multiple errors.
  • Added a dedicated error view for some classes of errors: Blogpost
  • Added support for PGP encryption: Blogpost
  • Fixed opening of attachments in the flatpak(s) (/tmp needed to be shared with the host system).
  • Added a dockercontainer to the kube repository that is used for CI and can be used for development.
  • Added ASAN and LSAN checkers (LLVM based memory/leak checkers) to sink and fixed various related issues.
  • Created a stresstest for sink which allows to continously run synchronizations and queries. This is used to trigger hard to find crashes.

Kube Commits, Sink Commits

Previous updates

More information on the Kolab Now blog!

“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.”

For more info, head over to: kube.kde.org

Categories: FLOSS Project Planets

Ortwin Glück: [Code] Gentoo enables PIE

Planet Apache - Thu, 2017-12-07 05:59
Gentoo has new profiles that require you to "recompile everything". That is technically not really necessary. Only static libraries really need recompiling.

Here is why:
A static library is just an archive of .o files (similar to tar), nothing more, and linking against a static library is roughly the same as just adding more .o files to the linker line. You can also link a static library into a shared library - the code in the static library is then just copied into the shared library (but the code then must be compiled with -fPIC, as with all other code that is used in shared libraries).

You can find static libs like so: equery b $(find /usr/lib/ /lib/ -name *.a) | awk '{ print $1; }' | sort | uniq Typically this yields packages like elfutils, libbsd, nss, iproute2, keyutils, texinfo, flex, db, numactl.

Categories: FLOSS Project Planets

Wunderkraut Sweden Blog: Adding a external JavaScript library to composer

Planet Drupal - Thu, 2017-12-07 05:37
Some module require that you download external Javascript-libraries, and in drupal 8 that should be done in Composer.  The module Masonry require the JavaScript library with the same name. So we need to include the package in composer.json, like:   "repositories":[ { "type":"composer", "url":"https://packages.drupal.org/8" }, { "type": "package", "package": { "name": "desandro/masonry", "version": "master", "type": "drupal-library", "dist": { "url": "https://unpkg.com/masonry-layout@4/dist/masonry.pkgd.min.js", "type": "file" } } }, And in the require part that is: "require":{ ... "desandro/masonry":"master",   ... }, And then we need to add libraries in extra part of we do not have that: "extra":{ ... "web/libraries/{$name}":[ "type:drupal-library… Read More
Categories: FLOSS Project Planets

Talk Python to Me: #141 Python tricks

Planet Python - Thu, 2017-12-07 03:00
How many Python developers do you know that learned Python quickly but then plateaued pretty quickly as well. Maybe this is someone you worked with or maybe it's even you. Python's clean and simple syntax can mean it's easy to learn but hard to master.
Categories: FLOSS Project Planets

ComputerMinds.co.uk: Aegir is ten!

Planet Drupal - Thu, 2017-12-07 02:11

Ten years ago today Adrian Rossouw committed the first code for the Aegir project. ComputerMinds have been involved in Aegir for many of those years, particularly one of our senior developers: Steven Jones. We asked him some questions about it to mark the occasion.

Categories: FLOSS Project Planets

Bryan Pendleton: Another milestone in computer chess

Planet Apache - Wed, 2017-12-06 23:43

This just in from the Deep Mind team: Mastering Chess and Shogi by Self-Play with a General Reinforcement Learning Algorithm

The AlphaZero algorithm is a more generic version of the AlphaGo Zero algorithm that was first introduced in the context of Go (29). It replaces the handcrafted knowledge and domain-specific augmentations used in traditional game-playing programs with deep neural networks and a tabula rasa reinforcement learning algorithm.


AlphaZero convincingly defeated all opponents, losing zero games to Stockfish and eight games to Elmo (see Supplementary Material for several example games), as well as defeating the previous version of AlphaGo Zero.


we analysed the chess knowledge discovered by AlphaZero. Table 2 analyses the most common human openings (those played more than 100,000 times in an online database of human chess games (1)). Each of these openings is independently discovered and played frequently by AlphaZero during self-play training. When starting from each human opening, AlphaZero convincingly defeated Stockfish, suggesting that it has indeed mastered a wide spectrum of chess play.

As for myself, I seem to hang pieces more frequently than I did a decade ago.

But I still love chess.

And, in that part of the world not (yet) inhabited solely by deep neural networks, That Norwegian Genius is going to play again, in London, next November: London Will Host FIDE World Chess Championship Match 2018.

Categories: FLOSS Project Planets

Codementor: Fetching huge datasets using iterator protocol

Planet Python - Wed, 2017-12-06 22:12
Reading large datasets using iterator protocol in Python
Categories: FLOSS Project Planets

Dirk Eddelbuettel: RcppArmadillo 0.8.300.1.0

Planet Debian - Wed, 2017-12-06 19:59

Another RcppArmadillo release hit CRAN today. Since our last release in October, Conrad kept busy and produced Armadillo releases 8.200.0, 8.200.1, 8.300.0 and now 8.300.1. We tend to now package these (with proper reverse-dependency checks and all) first for the RcppCore drat repo from where you can install them "as usual" (see the repo page for details). But this actual release resumes within our normal bi-monthly CRAN release cycle.

These releases improve a few little nags on the recent switch to more extensive use of OpenMP, and round out a number of other corners. See below for a brief summary.

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. RcppArmadillo integrates this library with the R environment and language--and is widely used by (currently) 405 other packages on CRAN.

A high-level summary of changes follows.

Changes in RcppArmadillo version 0.8.300.1.0 (2017-12-04)
  • Upgraded to Armadillo release 8.300.1 (Tropical Shenanigans)

    • faster handling of band matrices by solve()

    • faster handling of band matrices by chol()

    • faster randg() when using OpenMP

    • added normpdf()

    • expanded .save() to allow appending new datasets to existing HDF5 files

  • Includes changes made in several earlier GitHub-only releases (versions 0.8.300.0.0, and

  • Conversion from simple_triplet_matrix is now supported (Serguei Sokol in #192).

  • Updated configure code to check for g++ 5.4 or later to enable OpenMP.

  • Updated the skeleton package to current packaging standards

  • Suppress warnings from Armadillo about missing OpenMP support and -fopenmp flags by setting ARMA_DONT_PRINT_OPENMP_WARNING

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.

Categories: FLOSS Project Planets

Wallaroo Labs: Stateful Multi-Stream Processing in Python with Wallaroo

Planet Python - Wed, 2017-12-06 19:00
Wallaroo is a high-performance, open-source framework for building distributed stateful applications. In an earlier post, we looked at how Wallaroo scales distributed state. In this post, we’re going to see how you can use Wallaroo to implement multiple data processing tasks performed over the same shared state. We’ll be implementing an application we’ll call “Market Spread” that keeps track of the latest pricing information by stock while simultaneously using that state to determine whether stock order requests should be rejected.
Categories: FLOSS Project Planets

Justin Mason: Links for 2017-12-06

Planet Apache - Wed, 2017-12-06 18:58
  • In first, 3-D printed objects connect to WiFi without electronics

    This. is. magic.

    Physical motion—pushing a button, laundry soap flowing out of a bottle, turning a knob, removing a hammer from a weighted tool bench—triggers gears and springs elsewhere in the 3-D printed object that cause a conductive switch to intermittently connect or disconnect with the antenna and change its reflective state. Information—in the form of 1s and 0s—is encoded by the presence or absence of the tooth on a gear. Energy from a coiled spring drives the gear system, and the width and pattern of gear teeth control how long the backscatter switch makes contact with the antenna, creating patterns of reflected signals that can be decoded by a WiFi receiver.

    (tags: magic wifi whoa 3d-printing objects plastic gears springs)

Categories: FLOSS Project Planets

CiviCRM Blog: Registering multiple people for multiple different events - using Webforms - and LOTS of conditionals

Planet Drupal - Wed, 2017-12-06 18:37

We had a scenario where client runs a cluster of events, and folk sign up for these, and usually the registrants signs up for all events, but then they might invite mum to the Dinner, and brother John to the Talk, etc etc.

We wanted to achieve this on a single form with a single payment. We explored both CiviCart and Drupal Commerce but in the end concluded we could achieve this in a much lighter way with good old webforms.

The outcome is that up to 6 people can be registered for any combination of events, eg 

  • c1 registers for Events A, B, C, D, E and F
  • c2 registers for B, C and D
  • c3 registers for A and B
  • c4 registers for A and F
  • etc

To see the full gory details of the conditionals approach we took, please read the full blog on Fuzion's site.

Case studies and user storiesCiviEventDrupal
Categories: FLOSS Project Planets

Reuven Lerner: Registration is open for the January 2018 cohort of “Weekly Python Exercise”

Planet Python - Wed, 2017-12-06 17:49

When I started to program in Python more than 20 years ago, there weren’t a lot of resources out there. Sure, there were a handful of books, and a few Web sites, and (of course) forums and mailing lists. But that was about it.

Nowadays, Python is white-hot, with companies, universities, and individuals learning the language. Whether you’re a data scientist, Web developer, system administrator, test author, or hobbyist, you’re probably learning Python. Not surprisingly, there are oodles of books, courses, and resources for people learning the language.

And then? Well, then you’re on your own.

The problem is that there aren’t a lot of resources for intermediate-level Python developers to improve their fluency with the language. Sure, you can read through Stack Overflow and Reddit, as well as read blogs and watch conference videos. But given how much is out there for beginners, you would think that there would be something to help people who have already taken a Python course, and who are ready for the next stage.

The good news: I’m here to help.

More specifically: My course, Weekly Python Exercise, is just what the doctor ordered. WPE makes you a more fluent, more knowledgeable Python developer by forcing you to learn and practice your skills every week.

Every Tuesday, you’ll receive a new Python programming challenge. These challenges are designed to be relatively short and small, taking less than an hour of your time. The following Monday, you’ll receive my suggested answer, along with a description of why I chose to solve the problem in the way I did.

Along the way, you’ll learn about — or improve your understanding of — such topics as:

  • nested functions
  • iterators
  • generators
  • decorators
  • object inheritance
  • properties
  • threads and processes
  • the “logging” module
  • the “pickle” module

Most importantly, you’ll be solving these problems along with other developers from around the world. You’ll be able to participate in a forum, in which you can discuss possible solutions. Such interactions are the key to effective, deep learning, and I’m going to do my best to encourage active participation and discussion in our forum.

Moreover, I’ll offer live, online office hours every few weeks. This will give you a chance to ask me about the exercise questions, as well as the solutions. It’s your chance to discuss the exercises in greater depth.

I’m also going to include several multi-week projects, in which successive exercises build on previous ones. This will allow us to build larger projects, while remaining within the constraints of simple, weekly exercises.

This is the second time I’m offering Weekly Python Exercise. I’ve incorporated many suggestions I received from the first set of participants, making this the best way I can think of to improve your Python skills. I’ve improved the exercises, improved the social interactions, and made myself more available to discuss the questions (and answers) with all of the participants.

If you have a good knowledge of Python but want to make it even better, then Weekly Python Exercise is for you. But — and here’s the most important thing — the next cohort will be starting on January 2nd. After that, registration for WPE will be closed.

If you want to level up your Python, now is the time to sign up. I’m not sure when I’m next going to offer WPE, which means that once the course starts, you won’t be able to join.

If you have read a Python book, or taken a Python class, and want to know how to really “get” Python, look no further: Weekly Python Exercise is coming.

Click here to register for the January 2018 cohort of Weekly Python Exercise.

Wondering if WPE is for you? Contact me at reuven@lerner.co.il., and I’ll personally read (and respond to) your question.

If you’re on the fence, and want to sample WPE, you can just enter your e-mail address below, and receive (free of charge) two exercises from the most recent cohort:

Email Address

The post Registration is open for the January 2018 cohort of “Weekly Python Exercise” appeared first on Lerner Consulting Blog.

Categories: FLOSS Project Planets

Sam Ruby: Achieving Response Time Goals with Service Workers

Planet Apache - Wed, 2017-12-06 16:23

Service Workers enable a web application to be responsive even if the network isn't. Frameworks like AngularJS, React and Vue.js enable web applications to efficiently update and render web pages as data changes.

The Apache Software Foundation's Whimsy board agenda application uses both in combination to achieve a responsive user experience - both in terms of quick responses to user requests and quick updates based on changes made on the server.

From a performance perspective, the two cases easiest to optimize for are (1) the server fully up and running accessed across a fast network with all possible items cached, and (2) the application fully offline as once you make offline possible at all, it will be fast.

The harder cases ones where the server has received a significant update and needs to get that information to users, and even harder is when the server has no instances running and needs to spin up a new instance to process a request. While it is possible to do blue/green deployment for applications that are "always on", this isn't practical or appropriate for applications which only used in periodic bursts. The board agenda tool is one such application.

This article describes how a goal of sub-second response time is achieved in such an environment. There are plenty of articles on the web that show snippets or sanitized approaches, this one focuses on real world usage.

Introduction to Service Workers

Service Workers are JavaScript files that can intercept and provide responses to navigation and resource requests. Service Workers are supported today by Chrome and FireFox, and are under development in Microsoft Edge and WebKit/Safari.

Service Workers are part of a larger effort dubbed "Progressive Web Apps" that aim to make web applications reliable and fast, no matter what the state of the network may happen to be. The word "progressive" in this name is there to indicate that these applications will work with any browser to the best of that browser's ability.

The signature or premier feature of Service Workers is offline applications. Such web applications are loaded normally the first time, and cached. When offline, requests are served by the cache, and any input made by users can be stored in local storage or in an index db.

serviceworke.rs and The Offline Cookbook provide a number of recipes that can be used.

Overview of the Board Agenda Tool

This information is for background purposes only. Feel free to skim or skip.

The ASF Board meets monthly, and minutes are published publicly on the web. A typical meeting has over one hundred agenda items, though the board agenda tool assists in resolving most off them offline, leaving a manageable 9 officer reports, around 20 PMC reports that may or may not require action, and a handful of special orders.

While the full agenda is several thousand lines long, this file size is only a quarter of a megabyte or the size of a small image. The server side of this application parses the agenda and presents it to the client in JSON format, and the result is roughly the same size as the original.

To optimize the response of the first page access, the server is structured to do server side rendering of the page that is requested, and the resulting response starts with links to stylesheets, then contains the rendered HTML, and finally any scripts and data needed. This allows the browser to incrementally render the page as it is received. This set of scripts includes a script that can render any page (or component) that the board agenda tool can produce, and the data includes all the information necessary to do so. The current implementation is based on Vue.js.

Once loaded, traversals between pages is immeasurably quick. By that I mean that you can go to the first page and lean on the right arrow button and pages will smoothly scroll through the pages by at roughly the rate at which you can see the faces in a deck of cards shuffled upside down.

The pages generally contain buttons and hidden forms; which buttons appear often depends on the user who requests the page. For example, only Directors will see approve and unapprove buttons; and individual directors will only see one of these two buttons based on whether or not they have already approved the report.

A WebSocket between the server and client is made mostly so the server can push changes to each client; changes that then cause re-rendering and updated displays. Requests from the client to the server generally are done via XMLHttpRequest as it wasn't until very recently that Safari supported fetch. IE still doesn't, but Edge does.

Total (uncompressed) size of the application script is another quarter of a megabyte, and dependencies include Vue.js and Bootstrap, the latter being the biggest requiring over a half a megabyte of minimized CSS.

All scripts and stylesheets are served with a Cache-Control: immutable header as well as an expiration date a year from when the request was made. This is made possible by the expedient of utilizing a cache busting query string that contains the last modified date. Etag and 304 responses are also supported.

Offline support was added recently. Updates made when offline are stored in an IndexDB and sent as a batch when the user returns online. Having all of the code and data to render any page made this support very straightforward.

Performance observations (pre-optimization)

As mentioned at the top of this article, offline operations are virtually instantaneous. Generally, immeasurably so. As described above, this also applies to transitions between pages.

This leaves the initial visit, and returning visits, the latter includes opening the application in new tabs.

Best case response times for these cases is about a second. This may be due to the way that server side rendering is done or perhaps due to the fact that each page is customized to the individual. Improving on this is not a current priority, though the solution described later in this article addresses this.

Worst case response times are when there are no active server processes and all caches (both server side and client side) are either empty or stale. It is hard to get precise numbers for this, but it is on the order of eight to ten seconds. Somewhere around four is the starting of the server. Building the JSON form of the agenda can take another two given all of the validation (involving things like LDAP queries) involved in the process. Regenerating the ES5 JavaScript from sources can take another second or so. Producing the custom rendered HTML is another second. And then there is all of the client side processing.

In all, probably just under ten seconds if the server is otherwise idle. It can be a little more if the server is under moderate to heavy load.

The worst parts of this:

  1. No change is seen on the browser window until the last second or so.
  2. While the worst case scenario is comparatively rare in production, it virtually precisely matches what happens in development.
Selecting an approach

Given that the application can be brought up quickly in an entirely offline mode, one possibility would be to show the last cached status and then request updated information and process that information when received. This approach works well if the only change is to agenda data, but doesn't work so well in production whenever a script change is involved.

This can be solved with a window.location.reload() call, which is described (and somewhat discouraged) as approach #2 in Dan Fabulic's "How to Fix the Refresh Button When Using Service Workers". Note the code below was written before Dan's page was published, but in any case, Dan accurately describes the issue.

Taking some measurements on this produces interesting results. What is needed to determine if a script or stylesheet has changed is a current inventory from the server. This can consistently be provided quickly and is independent of the user requesting the data, so it can be cached. But since the data size is small enough, caching (in the sense of HTTP 304 reponses) isn't all that helpful.

Response time for this request in realistic network conditions when there is an available server process is around 200 milliseconds, and doesn't tend to vary very much.

The good news is that this completely addresses the "reload flash" problem.

Unfortunately, the key words here are "available server process" as that was the original problem to solve.

Fortunately, a combination approach is possible:

  1. Attempt to fetch the inventory page from the network, but give it a deadline that it should generally beat. Say, 500 milliseconds or a half a second.
  2. If the deadline isn't met, load potentially stale data from the cache, and request newer data. Once the network response is received (which had a 500 millisecond head start), determine if any scripts or stylesheets changed. If not, we are done.
  3. Only if the deadline wasn't met AND there was a change to a stylesheet or more commonly a script, perform a reload; and figure out a way to address the poor user experience associated with a reload.

Additional exploration lead to the solution where the inventory page mentioned below could be formatted in HTML and, in fact, be the equivalent to a blank agenda page. Such a page would still be less than 2K bytes, and performance would be equivalent to loading a blank page and then navigating to the desired page, in other words, immeasurably fast.


If you look at existing recipes, Network or Cache is pretty close; the problem is that it leaves the user with stale data if the network is slow. It can be improved upon.

Starting with the fetch from the network:

// attempt to fetch bootstrap.html from the network fetch(request).then(function(response) { // cache the response if OK, fulfill the response if not timed out if (response.ok) { cache.put(request, response.clone()); // preload stylesheets and javascripts if (/bootstrap\.html$/.test(request.url)) { response.clone().text().then(function(text) { var toolate = !timeoutId; setTimeout( function() { preload(cache, request.url, text, toolate) }, (toolate ? 0 : 3000) ) }) }; if (timeoutId) { clearTimeout(timeoutId); resolve(response) } } else { // bad response: use cache instead replyFromCache(true) } }).catch(function(failure) { // no response: use cache instead replyFromCache(true) })

This code needs to be wrapped in a Promise that provides a resolve function, and needs access to a cache as well as a variable named timeoutid and that determines whether or not the response has timed out.

If the response is ok, it and will be cached and a preload method will be called to load resources mentioned in the page. That will either be done immediately if not toolate, or after a short delay the timer expired to allow updates to be processed. Finally, if such a response was received in time, the timer will be cleared, and the promise will be resolved.

If either a bad response or no response was received (typically, this represents a network failure), the cache will be used instead.

Next the logic to reply from the cache:

// common logic to reply from cache var replyFromCache = function(refetch) { return cache.match(request).then(function(response) { clearTimeout(timeoutId); if (response) { resolve(response); timeoutId = null } else if (refetch) { fetch(event.request).then(resolve, reject) } }) }; // respond from cache if the server isn't fast enough timeoutId = setTimeout(function() {replyFromCache(false)}, timeout);

This code looks for a cache match, and if it finds one, it will resolve the response, and clear the timeoutId enabling the fetch code to detect if it was too late.

If no response is found, the action taken will be determined by the refetch argument. The fetch logic above passes true for this, and the timeout logic passes false. If true, it will retry the original request (which presumably will fail) and return that result to the user. This is handling a never should happen scenario where the cache doesn't contain the bootstrap page.

The above two snippets of code are then wrapped by a function, providing the event, resolve, reject, and cache variables, as well as declaring and initializing the timeoutId variable:

// Return a bootstrap.html page within 0.5 seconds. If the network responds // in time, go with that response, otherwise respond with a cached version. function bootstrap(event, request) { return new Promise(function(resolve, reject) { var timeoutId = null; caches.open("board/agenda").then(function(cache) { ... } })

Next, we need to implement the preload function:

// look for css and js files and in HTML response ensure that each are cached function preload(cache, base, text, toolate) { var pattern = /"[-.\w+/]+\.(css|js)\?\d+"/g; var count = 0; var changed = false; while (match = pattern.exec(text)) { count++; var path = match[0].split("\"")[1]; var request = new Request(new URL(path, base)); cache.match(request).then(function(response) { if (response) { count-- } else { fetch(request).then(function(response) { if (response.ok) cacheReplace(cache, request, response); count--; if (count == 0 && toolate) { clients.matchAll().then(function(clients) { clients.forEach(function(client) { client.postMessage({type: "reload"}) }) }) } }) } }) } };

This code parses the HTML response, looking for .css, and .js files, based on a knowledge as to how this particular server will format the HTML. For each such entry in the HTML, the cache is searched for a match. If one is found, nothing more needs to be done. Otherwise, the resource is fetched and placed in the cache.

Once all requests are processed, and if this involved requesting a response from the network, then a check is made to see if this was a late response, and if so, a reload request is sent to all client windows.

cacheReplace is another application specific function:

// insert or replace a response into the cache. Delete other responses // with the same path (ignoring the query string). function cacheReplace(cache, request, response) { var path = request.url.split("?")[0]; cache.keys().then(function(keys) { keys.forEach(function(key) { if (key.url.split("?")[0] == path && key.url != path) { cache.delete(key).then(function() {}) } }) }); cache.put(request, response) };

The purpose of this method is as stated: to delete from the cache other responses that differ only in the query string. It also adds the response to the cache.

The remainder is either straightforward or application specific in a way that has no performance relevance. The scripts and stylesheets are served with a cache falling back to network strategy. The initial preloading which normally could be as simple as a call to cache.addAll needs to be aware of query strings and for this application it turns out that a different bootstrap HTML file is needed for each meeting.

Finally, here is the client side logic which handles reload messages from the service worker:

navigator.serviceWorker.register(scope + "sw.js", scope).then(function() { // watch for reload requests from the service worker navigator.serviceWorker.addEventListener("message", function(event) { if (event.data.type == "reload") { // ignore reload request if any input or textarea element is visible var inputs = document.querySelectorAll("input, textarea"); if (Math.max.apply( Math, Array.prototype.slice.call(inputs).map(function(element) { return element.offsetWidth }) ) <= 0) window.location.reload() } }); }

This code watches for type: "reload" messages from the service worker and invokes window.location.reload() only if there are no input or text area elements visible, which is determined using the offsetWidth property of each element. Very few board agenda pages have visible input fields by default; many, however, have bootstrap modal dialog boxes containing forms.

Performance Results

In production when using a browser that supports Service Workers, requests for the bootstrap page now typically range from 100 to 300 milliseconds, with the resulting page fully loaded in 400 to 600 milliseconds. Generally, this includes the time it takes to fetch and render updated data, but in rare cases that may take up to an additional 200 milliseconds.

In development, and in production when there are no server processes available and when accessed using a browser that supports Service Workers, the page initially loads in 700 to 1200 milliseconds. It is not clear to me why this sees a greater range of response times; but in any case, this is still a notable improvement. Often in development, and in rare cases in production, there may be a noticeable refresh that occurs one to five seconds later.

Visitations by browsers that do not support service workers, and for that matter the first time a new user visits the board agenda tool, do not see any performance improvement or degradation with these changes.

Not a bad result from less than 100 lines of code.

Categories: FLOSS Project Planets

Django Weblog: Results of the Django/PyCharm Promotion 2017

Planet Python - Wed, 2017-12-06 16:14

We’re happy to report that our second iteration of the Django/PyСharm fundraising campaign - which we ran this summer - was a huge success. This year we helped raise a total of $66,094 USD for the Django Software Foundation! Last year (2016) we ran a similar campaign which resulted in a collective contribution of $50,000 USD to the cause. We’re happy we could raise even more money this year for the Django community!

If you missed the campaign here’s the essence of the past promotion: For 3 weeks this summer, Django developers could effectively donate to Django Software Foundation by purchasing a new individual PyCharm Professional annual subscription at 30% off, with all proceeds from the sales going to the Django Software Foundation. Read more details here.

All the money raised goes toward Django outreach and diversity programs: supporting DSF, the Django Fellowship program, Django Girls workshops, sponsoring official Django conferences, and other equally incredible projects.

We want to say huge thanks to the DSF for their active collaboration and making this fundraiser happen. We hope that in 2018 we’ll be able to make this yearly event even more successful!

The DSF general fundraising campaign is still on-going, and we encourage everyone to contribute to the success of Django by donating to DSF directly.

If you have any questions, get in touch with us at fundraising@djangoproject.com or JetBrains at pycharm-support@jetbrains.com.

Categories: FLOSS Project Planets

myDropWizard.com: Drupal 6 security update for Mailhandler!

Planet Drupal - Wed, 2017-12-06 15:37

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Mailhandler module to fix a Remote Code Execution (RCE) vulnerability.

Remote Code Execution vulnerabilities are scary - it basically means that an attacker can run arbitrary code on your site. However, there a number of mitigating factors in this case, so, it's recommended to read the security advisory for Drupal 7.

With the help of the D6LTS vendors, a new version was released for Drupal 6 as well.

You can also download the patch the patch.

If you have a Drupal 6 site using the Mailhandler module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Categories: FLOSS Project Planets

Isovera Ideas & Insights: The Company-wide Bookclub - Waste of Time or Change Catalyst?

Planet Drupal - Wed, 2017-12-06 13:39
Last summer, whilst I was on vacation, my staff plotted against me. It was a sneaky, devious plot intended to subterfuge my authority. They started a BOOK CLUB.
Categories: FLOSS Project Planets

Markus Koschany: My Free Software Activities in November 2017

Planet Debian - Wed, 2017-12-06 13:33

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

Debian Games Debian Java
  • New upstream versions this month: undertow, jackrabbit, libpdfbox2, easymock, libokhttp-java, mediathekview, pdfsam, libsejda-java, libsambox-java and libnative-platform-java.
  • I updated bnd (2.4.1-7) in order to help with the removal of Eclipse from Testing. Unfortunately there is more work to do and the only way forward is to package a newer version of Eclipse and to split the package in a way, so that such issues can be avoided in the future. P.S.: We appreciate help with maintaining Eclipse! (#681726)
  • I sponsored libimglib2-java for Ghislain Antony Vaillant.
  • I fixed a regression in libmetadata-extractor-java related to relative classpaths. (#880746)
  • I spent more time on upgrading Gradle to version 3.4.1 and finally succeeded. The package is in experimental now. Upgrading from 3.2.1 to 3.4.1 didn’t seem like a big undertaking but the 8 MB debdiff and ~170000 lines of code changes proved me wrong. I discovered two regressions with this version in mockito and bnd. The former one could be resolved but bnd requires probably an upgrade as well. I would like to avoid that at the moment because major bnd upgrades tend to affect dozens of reverse-dependencies, mostly in a negative way.
  • Netbeans was affected by a regression in jaxb and failed to build from source. (#882525) I could partly revert the damage but another bug in jaxb 2.3.0 is currently preventing a complete recovery.
  • I fixed two Java 9 transition bugs in libnative-platform-java (#874645) and  jedit (#875583).
Debian LTS

This was my twenty-first month as a paid contributor and I have been paid to work 14.75 hours (13 +1.75 from October) on Debian LTS, a project started by Raphaël Hertzog. In that time I did the following:

  • DLA-1177-1. Issued a security update for poppler fixing 4 CVE.
  • DLA-1178-1. Issued a security update for opensaml2 fixing 1 CVE.
  • DLA-1179-1. Issued a security update for shibboleth-sp2 fixing 1 CVE.
  • DLA-1180-1. Issued a security update for libspring-ldap-java fixing 1 CVE.
  • DLA-1184-1. Issued a security update for optipng fixing 1 CVE.
  • DLA-1185-1. Issued a security update for sam2p fixing 1 CVE.
  • DLA-1197-1. Issued a security update for sox fixing 7 CVE.
  • DLA-1198-1. Issued a security update for libextractor fixing 6 CVE. I also discovered that libextractor in buster/sid is still affected by more security issues and reported my findings as Debian bug #883528.
  • I packaged a new upstream release of osmo, a neat task manager and calendar application.
  • I prepared a security update for sam2p, which will be part of the next Jessie point release, and libspring-ldap-java. (DSA-4046-1)

Thanks for reading and see you next time.

Categories: FLOSS Project Planets

GNUnet News: gnURL 7.57.0 released

GNU Planet! - Wed, 2017-12-06 11:56

Today gnURL has been released in version 7.57.0, following the release of cURL 7.57.0.

The download is available in our directory on the GNU FTP and FTP mirrors (/gnu/gnunet/). 7.57.0 is the last version that will be available at https://gnunet.org/gnurl, future releases will be on the FTP.
If you are a distro maintainer for gnURL make sure to read the whole post with details below.

Categories: FLOSS Project Planets

Isovera Ideas & Insights: Configuration Management: Tips, Tricks & Perspective [NEDCamp 2017]

Planet Drupal - Wed, 2017-12-06 11:50
Sharing Tips, Tricks, and Perspective for and of Drupal 8’s Configuration Management System, “Configuration Management: Tips, Tricks & Perspective” was presented at NEDCamp 2017.
Categories: FLOSS Project Planets