Feed aggregator

Drupal core announcements: Drupal 8's minimum PHP version increased to 5.5.9

Planet Drupal - Thu, 09/07/2015 - 06:17

Pursuant to the discussion at [policy] Require PHP 5.5, the minimum PHP version of Drupal 8 has been raised to 5.5.9, and this change will be included in the next Drupal 8 beta (8.0.0-beta13).

(PHP 5.5.9 was chosen because it is also the same minimum version as Ubuntu's LTS, which in turn influenced Symfony 3.0, Travis CI, etc.)

This is a future-proofing move which buys us a few things:

  • Some nice language features and a built-in opcode cache.
  • Compatibility with the latest versions of various external dependencies, including Guzzle 6 and the upcoming Symfony 3.0
  • Better security for our end users, since PHP 5.4 will become end of life September 15, 2015 (most likely prior to Drupal 8's release).

We looked extensively into the adoption and hosting support of PHP 5.5 prior to making this move. While there is not widespread adoption of PHP 5.5 as of today, we nevertheless found that most hosts offer the option for PHP 5.5, due to PHP's security policy.

Categories: Elsewhere

Mediacurrent: Mediacurrent Dropcast: Episode 7

Planet Drupal - Thu, 09/07/2015 - 04:39

In this episode we celebrate the founding of our country by talking up a few modules we have discovered and enjoy. Ryan talks about the Image Field Focus module and how it makes cropping a joy without the gamble of a cropping image style. Bob waxes poetic about the WYSIWYG Field module, which is very similar to his WysiField module. As always we keep you up to date about Drupal 8 and Ryan brings it home with The Final Bell. This was recorded on the day before all went out for the holiday weekend so there are times where we derail the train. At least this time we have an excuse.

Categories: Elsewhere

Drupal core announcements: API module seeking co-maintainer

Planet Drupal - Thu, 09/07/2015 - 00:24

For the past 8+ years, Neil Drumm (drumm) has been maintaining the API module, and I've been co-maintaining it for the past 3+ years. (This is the module that builds and displays the Drupal API reference site api.drupal.org). Both of us have "some" other responsibilities in the Drupal ecosystem, and we'd like to find a new co-maintainer.

The ideal person would be:
- A good PHP coder familiar with and willing to follow the Drupal project's coding standards
- Familiar with the api.drupal.org site and its features
- Familiar with the API docs standards
- Familiar with both Drupal 7 and Drupal 8 core code (or at least familiar with the kinds of code it contains and the Drupalisms that it has), since both are displayed on the site
Of course, all of these "ideals" are negotiable and/or learnable, and it could be that a few co-maintainers would be better than just one.

The next step would be for the person or people who are interested to start making patches for a few issues, and once a few of those have happened, we would consider making you an official co-maintainer. The project page has a link to documentation for how to get a local API site set up, and the module also has a robust set of tests. The code in the API module is somewhat obtuse, but I'd be happy to start anyone out with a quick tour (or help you find an issue to work on). The module runs on Drupal 7 only at this time, and this is unlikely to need to change anytime soon (it displays Drupal 8 code but runs on Drupal 7, like the other *.drupal.org sites).

So if you're interested, you can either jump in and find an API module issue to work on and make a patch, or use my contact form or IRC to contact me and discuss.

Sorry... by policy, comments on this post are disabled, since it is going into the Core group (as well as Documentation).

Categories: Elsewhere

DrupalCon News: Save 100€ on Barcelona Tickets: Buy by Friday

Planet Drupal - Wed, 08/07/2015 - 20:32

Are you planning on attending DrupalCon Barcelona? If you are, we hope you’ll get your tickets this week and save 100€ in the process.

Every DrupalCon has varied ticket pricing levels, and DrupalCon Barcelona is no different. We’re offering earlybird pricing so that frugal DrupalCon attendees can get their tickets for less, but that pricing expires on Friday at 23:59 Barcelona local time (UTC +2).

For those looking at purchasing tickets, be aware that prices are as follows as we lead up to the convention:

Categories: Elsewhere

Lars Wirzenius: Obnam 1.12 released (backup software)

Planet Debian - Wed, 08/07/2015 - 16:59

I have just released version 1.12 of Obnam, my backup program. See the website at http://obnam.org for details on what it does. The new version is available from git (see http://git.liw.fi) and as Debian packages from http://code.liw.fi/debian, and uploaded to Debian, and soon in unstable.

The NEWS file extract below gives the highlights of what's new in this version. It includes the changes for version 1.11, which was a bug fix for 1.10 and not announced separately.

Version 1.12, released 2015-07-08

Bug fixes:

  • Steven Monai reported that using --one-file-system would crash, and it turned out to be a missing import.

  • Jan Niggemann reported that --exclude-caches no longer worked. This was due to a bug introduced when the option was moved to its own plugin (for cleaner code). The bug was masked by another bug, in the Yarn test suite. Both bugs have now been fixed.


  • Jan Niggemann translated the Obnam manpage to German. Due to cliapp not supporting other languages than English yet, the manual page lacks option descriptions.
Version 1.11, released 2015-07-02
  • The 1.10 release failed to correctly include the Green Albatross code, due to a missing line in setup.py. This has been fixed.
Categories: Elsewhere

Sven Hoexter: for the reproducible builds gang

Planet Debian - Wed, 08/07/2015 - 16:56

I gave up maintaining the LyX package about five years ago, but I still care. So I filled #9414 some time ago and it should be fixed for the next major release 2.2.0. So in case someone from the reproducible builds gang starts to look at LyX please hold the line and wait for the next major release instead.

Categories: Elsewhere

Sven Hoexter: F5 BigIP and 1K DH parameter vs SSL Labs

Planet Debian - Wed, 08/07/2015 - 16:35

So as a consequence of the weakdh issue(s) Qualys SSL Labs started to cap the rating at a B level if you provide DH cipher suites with 1K DH parameter. Now if you're terminating your TLS connections on F5s BigIP you're currently not able to change the DH parameter (they're random but of a fixed size). Finally a public comment from F5 written by Brian McHenry which is worth reading if you're running those boxes.

As a side note, what most people running on TMOS 11.6.x should've already done is preferring ECDHE over DHE, which would look like this:


That of course does not bring back the somewhat overrated A grade on the SSL Labs site. That boils down to choosing to provide DHE with 1K DH parameter or let everyone else use RSA with your 2K public key.

Honestly, for a public portal with a very wide range of users, I'm far from sure which one is the better choice. Looking at the weakest link "RSA+3DES" with TLSv1.0 is nothing that can convince the paranoid, but this cipher setting would bring you back the A grade:

Categories: Elsewhere

Drupal Watchdog: Caffeinated Drupal

Planet Drupal - Wed, 08/07/2015 - 16:34

One of the signs that you’re in a good coffee shop is if they serve their milk-based espresso drinks with an artful rosetta (floral pattern) on top. This is referred to as Latte art. At first glance, it may appear to be an offhand flourish by the barista – similar to a bartender flipping a bottle in the air before pouring a drink – but it is actually much more than that.

Latte art is a representation of the care and expertise that went into creating your drink: a good quality coffee bean; the ideal grind in order to pull an espresso with the right amount of crema (the oily brownish foam that sits on top of a good shot of espresso); milk that has been steamed just right to have a micro-foam consistency (uniform small bubbles throughout); and, of course, the perfect pour to blend the milk and espresso just right until a flower, heart, or other artful creation emerges on top.

While we sit back and enjoy today’s coffee – a Brazil Yellow Bourbon Latte (amazing bitter cocoa flavors, is this a latte or a hot chocolate?!?) – let’s consider how an optimally performing Drupal site compares to the creation of latte art.

There are many factors that contribute to a high performance Drupal site. For starters, we can look at factors such as code quality, the use of caches where possible, database configuration, and front-end caching. For a Drupal site to perform at its best, all of these components must be done well. Even a small misconfiguration or a bit of buggy code can be enough to slow a site to a crawl, especially when serving a large amount of traffic. The same can be said for latte art: if the coffee beans aren’t fresh enough to produce crema, or the milk isn’t foamed properly, or the pour of the milk isn’t done with the correct technique, the result will be an ordinary-looking – and possibly poor-tasting – drink.

Categories: Elsewhere

Mpumelelo Msimanga: Drupal: Filters for External Data Views

Planet Drupal - Wed, 08/07/2015 - 16:18
Drupal: Filters for External Data Views

A Drupal View that uses Views Database Connector (VDC) to show external database tables will not have all features of a “normal” View. For example, select filters are only available for list fields, references and taxonomy terms. In this post I use two modules to improve the exposed filters in my external data View.

Categories: Elsewhere

Realityloop: Custom Formatters 7.x-2.4

Planet Drupal - Wed, 08/07/2015 - 07:51
8 Jul Stuart Clark

Full disclaimer, I am saying this as the developer of the module, but it is definitely the module that I am the most proud of.

That’s Custom Formatters with a capital CF; custom formatters (with lower case characters) are a core part of Drupal, they are the layer that takes Field data from the database and presents it to the frontend of your website in a more visually appealing style.

The Custom Formatters module quite simply adds the ability for site builders and developers to create or tweak their own custom formatters from within the website, never needing to touch the site file system.

And now, with Custom Formatters 7.x-2.4, it’s even better.


What’s new in Custom Formatters 7.x-2.4?
  1. New Formatter format/engine; Formatter presets
    This is the big one, the catalyst for the new release; Formatter presets give you the ability to take complex Formatters with settings and turn them into new simplified, end-user approved formatters.

    More on this below.
  2. Support for Display Suite fields
    I’ve been a big fan of Display Suite (DS) since I first came across it years ago. Custom Formatters did have support for DS in the Drupal 6 version, but I had made the decision to not support it in Drupal 7 due to DS’s own Code fields. Due to popular demand (my self included), that decision has been reversed.
  3. Fixes to the HTML + Token format
    HTML + Tokens was always supposed to be the format that made this module site builder friendly, but to various issues with native Field tokens in Drupal 7 it has never worked overly well. I’m happy to say that this is no longer the case, and HTML + Tokens formatters work extremely well.

    More on this below.
  4. Miscellaneous bug fixes.


How to use Custom Formatters?

Using custom formatters is relatively straight forward, anyone who has used any CTools Export UI based module (Views, Context, etc) should be familiar with the user interface:

By default it comes with some example formatters, and you can import others from your own collection or from CustomFormatters.com, but chances are you are most likely going to want to create your own Custom Formatters.

To do so, simply click the + Add button and you will be presented with the following interface:

You will need to provide the following information:

  1. Formatter name
    The human readable name of the formatter, what the site-builder, or possibly end user will see when choosing a formatter.

    Entering this value will auto-generate the Machine name, which can also be manually edited.
  2. Description
    Only used within the Custom Formatters interface, useful to explain what the purposes of the formatter are, where it’s to be used and what modules it requires.
  3. Format
    The format/engine of the formatter you are about to create. Out of the box there are three formats, but additional modules are able to provide additional formats. The format determines the method of how the Formatter is created, and as such I will go into more detail for each individual format below.
  4. Field type(s)
    Depending on the chosen format, you need to assign the formatter to one or many field types types (image, file, textfield, etc).
  5. Formatter
    The formatter interface itself is dependent on the chosen format, more details on each format below.

Once you have created your formatter, you can preview the formatter within the Preview interface. This allows you to apply the formatter to an existing field on an existing entity, or if the Devel generate module (provided by the Devel module) is present you can apply the formatter against a devel generated item.

Lastly, ensure you save your formatter, as you don’t want all your hard work to go down the drain. Alternatively, Save & Edit frequently during the creation of the formatter.


Format types

Out of the box there are three formats available with Custom Formatters, but the module is written in such a way that any 3rd part module could add an additional format.



The PHP format was the original format engine for the Custom Formatters module, it mimics as closely to writing a formatter within a Drupal custom module as feasible, and as such is only recommended for use by those with knowledge of PHP and the Drupal API.

The PHP format is provided with all required data for writing a formatter in the $variable array, as well as an individual variable per array key ($variable['#items'] is the same as $items):

  1. $obj_type: The entity type (node, taxonomy_term, etc)

  2. $object: The entity object.

  3. $field: The field definition.

  4. $instance; The field instance.

  5. $langcode; The language code.

  6. $items; An array of all field item data for formatting.

  7. $display; The formatter display settings and formatter settings.

With this data you are free to do with what you will. However, in general a standard pattern is to iterate over the $items array and populate an $elements array which is finally returned to Drupal:

  1. $elements = array();
  3. foreach ($items as $delta => $item) {
  4. $elements[$delta] = array(
  5. '#markup' => $item['value'],
  6. );
  7. }
  9. return $elements;

This pattern allows support for multiple items, as well as taking advantage of Drupal's Render Arrays system.


HTML + Tokens

The HTML + Tokens format allows you to create simple and easy Custom Formatters with no more than HTML and Tokens, as the name implies. While this has been available for a long time in Custom Formatters, in the latest release it has been vastly improved upon, primarily with improved support for the Entity tokens module (provided by the Entity API module).

Any entity type token can be used, as well as chained tokens specific to the field in use, but it is important to take into account where the formatter will be used when choosing the formatters. For instance, if you were to use a Taxonomy term token on an Image field formatter that is going to be displayed on a Node entity, the Taxonomy term token will not work.

The markup in your formatter is rendered per field item, so if you are using a multi-value field, each value will run through your formatter. This is where the improvements to the Entity tokens module support is important, as you can target the field values directly.

If you are formatting an Image field, you can target the URL using the Entity tokens chained token [file:url], which is unique to each item value.

In addition to the improvements with the Entity tokens module integration, I also released a new module, Field tokens, which adds two different type of tokens which are extremely useful with HTML + Tokens formatters:

  1. Formatted field tokens
    Tokens that allow you to pass the field through an existing Formatter with provided formatter settings.

    Example: [formatted_field-image:image:image_style-thumbnail] would pass the current image field value through the Drupal core Image formatter via the thumbnail image style.
  2. Field property tokens
    Tokens that provide you with the specific property of a field value.
    Example: [field_property:alt] would return the Alt value for the current image field value.


Formatter preset

A new addition to the Custom Formatters module, and while maybe not the most obvious, it is a great addition that was a direct response to the Wysiwyg Fields module.

The Formatter preset format allows you to replace formatters with complex formatter settings forms with simple preconfigured formatters with more user friendly names. Especially useful when the formatter choice is exposed to a non-technical user.

Below you can see an example of the Youtube field and formatter in use in Wysiwyg Fields with it’s abundance of formatter settings (on the left) and a Formatter preset of the same formatter preconfigured as desired (on the right).

It’s obvious a lot simpler, so simple in fact that there’s no evidence that a formatter or formatter settings are present, it will just work.

Creating a Formatter preset is quite different to the other Custom Formatter formats. There is no textarea field, instead you are presented with an interface similar to screenshot below:

Things to note are:

  1. Formatter
    The existing formatter which you are using as a source for this Formatter preset.

  2. Formatter settings
    Everything below the Formatter field are specific to the chosen Formatter, they are that Formatter’s settings.

Extremely simple, but a huge improvement to the user experience.



While not an out of the box Format for the Custom Formatters module, I think it’s important to mention this for two reasons:

  1. Drupal 8 is coming, and it’s bringing the Twig templating system with it.
  2. This is a great example of how other modules can create new Custom Formatters format types.

The Twig format requires the Twig filter module, which doesn’t yet have a stable release, but is still well worth a look.

The interface is much like the PHP and HTML + Tokens formats, with the difference of using the Twig templating language, which is said to be simpler for frontend developers.


Using a formatter

Once you’ve created your formatter, that formatter can be used in many different ways, as the the Formatter system is just the theme layer to Drupal’s field system, so in general a Formatter should be able to be used anywhere a Drupal field is used.

Examples of ways to use a Formatter include, but are not limited to:

  1. Drupal’s core Manage display interface

  2. Views using the Field style

  3. Wysiwyg Fields

  4. Formatted field tokens with the Field tokens and Token filter modules



CustomFormatters.com is a companion website for the CustomFormatters module.

It contains various Formatters which can be used as they are, or as examples of how to write your own formatters.

There are also plans to provide the ability for uses to share their own formatters with others.

The website is completely open source, and anyone wishing to steal the site or contribute to the site can do so at https://github.com/Decipher/customformatters.com


Download Custom Formatters now

Head on over to the Custom Formatters project page and download Custom Formatters 7.x-2.3 now.

drupal planetdrupal 7custom formatters
Categories: Elsewhere

OpenConcept: The Drupal North Code Sprint

Planet Drupal - Tue, 07/07/2015 - 23:40

The inaugral Drupal North Regional Summit was a blast!

The official Drupal North sprint was held on Sunday, June 28th, starting around 10am and ending at 4pm, in Ryerson University's Rogers Communication Centre Transmedia Zone. 21 attendees showed up from all over Canada, the United States, and even Costa Rica:

After everyone introduced themselves, Cottser and I gave an introduction to writing patches, and how issues move through the issue queue from "Active" to "Closed" (video to follow).

Then, we paired up to get Drupal 8, Drush, and Drupal Console working on our computers, and work on issues we were interested in. We worked on 9 issues:

At time-of-writing, 2 of these issues are fixed, and 5 more need review.

Also, congratulations to Jeremy Knab for his first commit mention in Drupal core (from #2501701)!

Overall, we had a great time and learned a lot! Thanks to everyone who came out, and to the DrupalNorth organizers for organizing everything!


AttachmentSize DrupalNorth 2015 sprinters sitting around a table, introducing themselves.167.46 KB DrupalNorth 2015 sprinters sitting around a table, listening to Cottser.189.44 KB DrupalNorth 2015 sprinters gathering around and setting up a television, about to set up Drupal Console.164.66 KB cyborg_572 and crasx setting up.177.64 KB Cottser demonstrating how to turn on the automated testing module in Drupal 8 to enzo, bohemier, adamwhite, and HelloNewman.142.43 KB bohemier and adamwhite working together on an issue and laughing.143.63 KB HelloNewman eating a Timbit while nafes & Cottser concentrate on their work. In the foreground is an iconic Tim Hortons coffee.93.58 KB Topic: Primary Image: 
Categories: Elsewhere

Darryl Norris's Blog: How To Request A Node via REST Using Web Services in Drupal 8

Planet Drupal - Tue, 07/07/2015 - 22:05

Drupal 8 is going to be a central place to store data and can easily connect with different third-party applications. Dries Buytaert has talked about this idea multiple times in DrupalCon Austin and DrupalCon Bogota, where Drupal 8 is going to be an API to connect to other places. For this reason, Drupal 8 is now integrated with web services in core. In other words, this is an easy way to export data into Hal-JSON, JSON, and XML. I decided to start playing with web services in Drupal 8 to see how I can export my data in JSON format and connected with third party app. I found many tutorials that talks about Drupal how to export JSON data using the Views module, which for many use cases can be very good. I started to think, “What...Read more
Categories: Elsewhere

Acquia: How to Evaluate Drupal Modules for Performance Optimization

Planet Drupal - Tue, 07/07/2015 - 19:58

Drupal was designed from the ground-up to be modular. Once you install Drupal core, you can add any number of modules to enhance Drupal's basic functions.

Unfortunately, contributed modules can also impede performance. For example, it's common to find contributed third-party modules that are incompatible with newer versions of Drupal, or other modules. Besides being a security hassle, this can often curb performance.

Evaluating Drupal modules for such issues is thus essential for a smooth Drupal experience. As part of this ongoing blog series on ways to improve Drupal website performance, let’s review how you can evaluate modules.

General module evaluation

The first step in module evaluation is to consider general usage reports, statistics, and maintainer reputation. One by one, go through the following:

  • Does the module officially support your version of Drupal?
  • Good maintainers write good code. If you see the same maintainer's name crop up on a number of well-regarded modules, you know you will at least get quality code.
  • A high maintainer activity level (i.e. commits to a module) indicates a proactive maintainer who takes care of issues quickly.
  • Higher total module usage generally means it's a well-regarded module with fewer performance issues.
  • A large number of stagnant, open issues can point to poor code quality and maintenance.
  • Sudden changes in usage patterns over a short period of time can be indicative of performance issues. For example, if people suddenly stop using a popular module, it could mean that users encountered performance or security problems.

Once you've gone through these steps, you can undertake a performance evaluation.

Module performance evaluation

Now you need to analyze the module performance on your own site.

  • Record site performance before installing any modules. This should include page load time, server load, and user scenario completion time.
  • Record site performance immediately after installing the module.
  • Monitor memory usage continuously to correlate the performance before and after module installation.
  • Perform the same steps for every module individually over time.

These actions will give you quantifiable results on each module's performance as it relates to your site. You might find that highly rated, widely used modules sometimes don't play well with your version of Drupal, while less used modules work perfectly well.

Final questions

Besides evaluating performance, you also need to ask a few questions before using a module.

  • Does the module scale? A module that works perfectly well for a small enterprise website might break when used on a large community-powered platform. Scale is difficult to measure but it is one of the biggest performance bottlenecks in any website.
  • Is performance a top priority? While performance is important, it is by no means necessary for certain types of websites. For example, a small corporate website visited mostly by internal team members may not need top-notch performance.
  • What happens if the module fails? This is an important question. If your module stops working, does it break the site completely, or can the users at least access parts of the site? For example, if the module that controls the login system fails, your users won't be able to use their accounts at all.
  • Do I really need the module? Far too many websites use more modules than necessary. This leads to "module bloat." Ask yourself: “Do I really need this module? Is there a simple manual workaround to enable this function?” If "yes," try to avoid using a module. Keep in mind that the fewer modules you use, the smaller chance of failure.

Modules are crucial for running a Drupal website, but they are also one of the leading causes of website performance issues. Evaluating and understanding modules is essential for running a fast and secure Drupal website.

Tags:  acquia drupal planet
Categories: Elsewhere

Drupal core announcements: Drupal 8 core updates for July 7th, 2015

Planet Drupal - Tue, 07/07/2015 - 19:40

Since the last Drupal 8 Core Update, DrupalCon Los Angeles took place, the proposed organizational structure for the Drupal project was approved and MAINTAINERS.txt was updated to reflect this (although it still needs to be updated in the Drupal 7 branch), and the Drupal Association announced updates to their 2015 financial plan.

What's new with Drupal 8?

Drupal 8.0.0-beta11 and 8.0.0-beta12 were released, a new category for issues, plan, was added to categorize meta issues, the Drupal 8 Security bug bounty program was launched, Angie "webchick" Byron analyzed Drupal major version adoption and walked us through the new DrupalCI testing infrastructure, hook_update_N() became required for core patches that introduce data model changes, the number of outstanding criticals was reduced to a new all-time low of 15, and for a while, every single critical was RTBC or being addressed!

Some other highlights of the month were:

How can I help get Drupal 8 finished?

See Help get Drupal 8 released! for updated information on the current state of the software and more information on how you can help.

We're also looking for more contributors to help compile these posts. Contact mparker17 if you'd like to help!

Drupal 8 In Real Life Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.0.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. If you'd like to volunteer for helping to draft these posts, please follow the steps here!

Categories: Elsewhere

Lunar: Reproducible builds: week 10 in Stretch cycle

Planet Debian - Tue, 07/07/2015 - 15:46

What happened about the reproducible builds effort this week:

Media coverage

Daniel Stender published an English translation of the article which originally appeared in Linux Magazin in Admin Magazine.

Toolchain fixes

Fixes landed in the Debian archive:

  • Lunar uploaded docbook-to-man/1:2.0.0-34 which removes a timestamp in generated manpages. Original patch by Chris Lamb.
  • Stefano Rivera uploaded dh-python/1.20150628-1 which now sorts namespace files. Original patch by Chris Lamb.
  • Christian Hofstaedtler uploaded ruby2.2/2.2.2-2 which now uses UTC for the dates in gemspec files. Original patch by Chris Lamb.

Lunar submitted to Debian the patch already sent upstream adding a --clamp-mtime option to tar.

Patches have been submitted to add support for SOURCE_DATE_EPOCH to txt2man (Reiner Herrmann), epydoc (Reiner Herrmann), GCC (Dhole), and Doxygen (akira).

Dhole uploaded a new experimental debhelper to the reproducible repository which exports SOURCE_DATE_EPOCH. As part of the experiment, the patch also sets TZ to UTC which should help with most timezone issues. It might still be problematic for some packages which would change their settings based on this.

Mattia Rizzolo sent upstream a patch originally written by Lunar to make the generate-id() function be deterministic in libxslt. While that patch was quickly rejected by upstream, Andrew Ayer came up with a much better one… which sadly could have some performance impact. Daniel Veillard replied with another patch that should be deterministic in most cases without needing extra data structures. It's impact is currently being investigated by retesting packages on reproducible.debian.net.

akira added a new option to sbuild for configuring the path in which packages are built. This will be needed for the srebuild script.

Niko Tyni asked Perl upstream about it using the __DATE__ and __TIME__ C processor macros.

Packages fixed

The following 143 packages became reproducible due to changes in their build dependencies: alot, argvalidate, astroquery, blender, bpython, brian, calibre, cfourcc, chaussette, checkbox-ng, cloc, configshell, daisy-player, dipy, dnsruby, dput-ng, dsc-statistics, eliom, emacspeak, freeipmi, geant321, gpick, grapefruit, heat-cfntools, imagetooth, jansson, jmapviewer, lava-tool, libhtml-lint-perl, libtime-y2038-perl, lift, lua-ldoc, luarocks, mailman-api, matroxset, maven-hpi-plugin, mknbi, mpi4py, mpmath, msnlib, munkres, musicbrainzngs, nova, pecomato, pgrouting, pngcheck, powerline, profitbricks-client, pyepr, pylibssh2, pylogsparser, pystemmer, pytest, python-amqp, python-apt, python-carrot, python-crypto, python-darts.lib.utils.lru, python-demgengeo, python-graph, python-mock, python-musicbrainz2, python-pathtools, python-pskc, python-psutil, python-pypump, python-repoze.sphinx.autointerface, python-repoze.tm2, python-repoze.what-plugins, python-repoze.what, python-repoze.who-plugins, python-xstatic-term.js, reclass, resource-agents, rgain, rttool, ruby-aggregate, ruby-archive-tar-minitar, ruby-bcat, ruby-blankslate, ruby-coffee-script, ruby-colored, ruby-dbd-mysql, ruby-dbd-odbc, ruby-dbd-pg, ruby-dbd-sqlite3, ruby-dbi, ruby-dirty-memoize, ruby-encryptor, ruby-erubis, ruby-fast-xs, ruby-fusefs, ruby-gd, ruby-git, ruby-globalhotkeys, ruby-god, ruby-hike, ruby-hmac, ruby-integration, ruby-ipaddress, ruby-jnunemaker-matchy, ruby-memoize, ruby-merb-core, ruby-merb-haml, ruby-merb-helpers, ruby-metaid, ruby-mina, ruby-net-irc, ruby-net-netrc, ruby-odbc, ruby-packet, ruby-parseconfig, ruby-platform, ruby-plist, ruby-popen4, ruby-rchardet, ruby-romkan, ruby-rubyforge, ruby-rubytorrent, ruby-samuel, ruby-shoulda-matchers, ruby-sourcify, ruby-test-spec, ruby-validatable, ruby-wirble, ruby-xml-simple, ruby-zoom, ryu, simplejson, spamassassin-heatu, speaklater, stompserver, syncevolution, syncmaildir, thin, ticgit, tox, transmissionrpc, vdr-plugin-xine, waitress, whereami, xlsx2csv, zathura.

The following packages became reproducible after getting fixed:

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

  • cdo/1.6.6+dfsg.1-1 uploaded by Alastair McKinstry.
  • dsdo/1.6.36-6 by Agustin Martin Domingo.
  • liboro-java/2.0.8a-11 by Emmanuel Bourg.
  • simgrid/3.11.1-10 uploaded by Martin Quinson, original patch by akira.

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


A new package set for the X Strike Force has been added. (h01ger)

Bugs tagged with “locale” are now visible in the statistics. (h01ger)

Some work has been done add tests for NetBSD. (h01ger)

Many changes by Mattia Rizzolo have been merged on the whole infrastructure:

  • IRC notifications when known reproducible packages stops buildig successfully.
  • Packages marked ftbfs_due_to_obsolete_dependencies now appears as FTBFS on the package tracker.
  • When listing packages affected by an issue, packages without bugs are grouped together, making it easier to spot the ones who requires work.
  • Both build logs are now saved separately. A diff between the two files is available.
  • The text output of debbindiff is now available as well for easier search and reports.
  • Build logs and debbindiff output are now stored compressed with gzip.
  • The builder used for a given test is now recorded in the database.
  • The manual scheduler available from Alioth gained new options:
    • -i/--issues: schedule all packages affected by the given issue.
    • -r/--status: schedule all packages with the given status.
    • -b/--before: schedule all packages built before the given date
    • -t/--after: schedule all packages built after the given date.
    • --noisy: notify the IRC channel also when the build starts, with a URL to watch it in real time.
debbindiff development

Version 26 has been released on June 28th fixing the comparison of files of unknown format. (Lunar)

A missing dependency identified in python-rpm affecting debbindiff installation without recommended packages was promptly fixed by Michal Čihař.

Lunar also started a massive code rearchitecture to enhance code reuse and enable new features. Nothing visible yet, though.

Documentation update

josch and Mattia Rizzolo documented how to reschedule packages from Alioth.

Package reviews

142 obsolete reviews have been removed, 344 added and 107 updated this week.

Chris West (Faux) filled 13 new bugs for packages failing to build from sources.

The following new issues have been added: snapshot_placeholder_replaced_with_timestamp_in_pom_properties, different_encoding, timestamps_in_documentation_generated_by_org_mode and timestamps_in_pdf_generated_by_matplotlib.

Categories: Elsewhere

Gábor Hojtsy: Win prizes by playing with Drupal 8's multilingual site building features!

Planet Drupal - Tue, 07/07/2015 - 15:03

Drupal 8 packs a historic amount of site building features which make producing websites easier than ever with core or just a couple contributed modules only. There are already various live Drupal 8 multilingual sites using little more but core.

It is hard to grasp the many things with useful levers and knobs in Drupal 8. Think about combining views with entity view modes and blocks; block language visibility with menus; user preferences with comment submission; language filtering and entity rendering; translatable fields with administration views; and so on and on.

Wouldn't it be fun to experiment with the possibilities and come up with clever ways to combine core features to solve common problems? You may be familiar with the name and format of O'Reilly's Hacks Series which reclaims the term "hacking" for the good guysfolks — innovators who explore and experiment, unearth shortcuts, create useful tools, and come up with fun things to try on their own.

Long story short, hereby, we announce the Drupal 8 multilingual site building hacks contest!

  1. Come up with clever ways to combine Drupal 8 core features (and if needed one or at most two contributed modules) to fulfill a multilingual site building need.
  2. Write up the steps taken. See an example in hack #1. (We'll do light editing of the post if needed, don't let perfection be the enemy of good).
  3. Register on http://drupal8multilingual.org/user to submit entries (requires approval for spam protection).
  4. Submit entries by end of day (CEST) July 31st.
  5. One person may submit as many entries as they wish.
  6. All entries will be published after review (and possible light editing).
What is in it for you?

The top 3 best hacks will receive unique presents from Hook42 and Amazee Labs! (Further sponsors welcome). You'll either receive the presents at DrupalCon Barcelona or we'll mail it to you if you are not coming to DrupalCon. This is of course additionally to the joy of getting to play with some of the less frequented but definitely no less fun features of Drupal 8.

What is in it for us?

All hacks will be published under Creative Commons Attribution-ShareAlike 4.0, so the community will benefit. Additionally to that Gábor Hojtsy and Vijayachandran Mani are building an open source presentation with the best tips (same license). This will be presented at Drupalaton Hungary and DrupalCon Barcelona. Similar to our existing open source workshop, everyone will be able to present this at local meetups and camps or follow along at home at their own pace.

What kind of hacks are we looking for?

Hack #1 is hopefully a good example. Really the only common thread between the hacks would be to satisfy a multilingual site need or use multilingual features in some other clever way (even for features that are not necessarily multilingual). Some ideas for hacks that may help you start off experimenting:

  1. Swap textual site logo Need to swap a site logo with text on it for different languages? Use a translatable custom block with an image field. Configure the display mode and add some custom CSS if needed.
  2. Translator todo helper Create a views block for content translators to summarize the number of outdated translations they have to update (and link to content administration filtered to that language)
  3. Language dependent front page Use block visibility to display up to date content on a well maintained language while an About us / Contact us page on languages where resources are limited to maintain useful fresh content.

Of course these are just some things we made up (although still eligible for the contest). Looking for your creative ideas and solutions!

Questions, concerns? Contact us!

This is a crosspost from http://www.drupal8multilingual.org/hacks.

Categories: Elsewhere

InternetDevels: 6 Reasons Why You Should Use Drupal For Website Development

Planet Drupal - Tue, 07/07/2015 - 14:50

Our guest blogger Jack Dawson, founder of Big Drop Inc, expains why he thinks Drupal is the best choice for website development services.

Read more
Categories: Elsewhere

ERPAL: Drop Guard vs. Drupalgeddon - The 1:0 knockout in just a few minutes

Planet Drupal - Tue, 07/07/2015 - 11:00

Get ready to rumble! Watch how Drop Guard won against Drupalgeddon on 15.10.2014 at 6:00 PM in this live webinar! We're going to run a live demo re-enacting the whole epic match, and you'll learn about the techniques and strategies that Drop Guard uses to sucker-punch any future Drupal security threats. Don't expect a second round: it'll be a technical KO within minutes!

This free, 45-minute webinar takes place via Google Hangout on 27.07.2015 at 4 PM GMT+2. You'll learn the following:


  1. How to set up an automated workflow to keep your Drupal site updated and secure
  2. Three simple prerequisites for starting with Drop Guard
  3. How Drop Guard integrates with your individual development and deployment workflows


We'll use a Drupalgeddon-infected Drupal installation including several other modules with security issues. This exclusive live demo shows the current status of Drop Guard. All attendees also get free Drop Guard access until the end of September 2015. All attendees get free Drop Guard access until the end of September 2015.


Sign up for free!


Categories: Elsewhere

Petter Reinholdtsen: MPEG LA on "Internet Broadcast AVC Video" licensing and non-private use

Planet Debian - Tue, 07/07/2015 - 09:50

After asking the Norwegian Broadcasting Company (NRK) why they can broadcast and stream H.264 video without an agreement with the MPEG LA, I was wiser, but still confused. So I asked MPEG LA if their understanding matched that of NRK. As far as I can tell, it does not.

I started by asking for more information about the various licensing classes and what exactly is covered by the "Internet Broadcast AVC Video" class that NRK pointed me at to explain why NRK did not need a license for streaming H.264 video:

According to a MPEG LA press release dated 2010-02-02, there is no charge when using MPEG AVC/H.264 according to the terms of "Internet Broadcast AVC Video". I am trying to understand exactly what the terms of "Internet Broadcast AVC Video" is, and wondered if you could help me. What exactly is covered by these terms, and what is not?

The only source of more information I have been able to find is a PDF named AVC Patent Portfolio License Briefing, which states this about the fees:

  • Where End User pays for AVC Video
    • Subscription (not limited by title) – 100,000 or fewer subscribers/yr = no royalty; > 100,000 to 250,000 subscribers/yr = $25,000; >250,000 to 500,000 subscribers/yr = $50,000; >500,000 to 1M subscribers/yr = $75,000; >1M subscribers/yr = $100,000
    • Title-by-Title - 12 minutes or less = no royalty; >12 minutes in length = lower of (a) 2% or (b) $0.02 per title
  • Where remuneration is from other sources
    • Free Television - (a) one-time $2,500 per transmission encoder or (b) annual fee starting at $2,500 for > 100,000 HH rising to maximum $10,000 for >1,000,000 HH
    • Internet Broadcast AVC Video (not title-by-title, not subscription) – no royalty for life of the AVC Patent Portfolio License

Am I correct in assuming that the four categories listed is the categories used when selecting licensing terms, and that "Internet Broadcast AVC Video" is the category for things that do not fall into one of the other three categories? Can you point me to a good source explaining what is ment by "title-by-title" and "Free Television" in the license terms for AVC/H.264?

Will a web service providing H.264 encoded video content in a "video on demand" fashing similar to Youtube and Vimeo, where no subscription is required and no payment is required from end users to get access to the videos, fall under the terms of the "Internet Broadcast AVC Video", ie no royalty for life of the AVC Patent Portfolio license? Does it matter if some users are subscribed to get access to personalized services?

Note, this request and all answers will be published on the Internet.

The answer came quickly from Benjamin J. Myers, Licensing Associate with the MPEG LA:

Thank you for your message and for your interest in MPEG LA. We appreciate hearing from you and I will be happy to assist you.

As you are aware, MPEG LA offers our AVC Patent Portfolio License which provides coverage under patents that are essential for use of the AVC/H.264 Standard (MPEG-4 Part 10). Specifically, coverage is provided for end products and video content that make use of AVC/H.264 technology. Accordingly, the party offering such end products and video to End Users concludes the AVC License and is responsible for paying the applicable royalties.

Regarding Internet Broadcast AVC Video, the AVC License generally defines such content to be video that is distributed to End Users over the Internet free-of-charge. Therefore, if a party offers a service which allows users to upload AVC/H.264 video to its website, and such AVC Video is delivered to End Users for free, then such video would receive coverage under the sublicense for Internet Broadcast AVC Video, which is not subject to any royalties for the life of the AVC License. This would also apply in the scenario where a user creates a free online account in order to receive a customized offering of free AVC Video content. In other words, as long as the End User is given access to or views AVC Video content at no cost to the End User, then no royalties would be payable under our AVC License.

On the other hand, if End Users pay for access to AVC Video for a specific period of time (e.g., one month, one year, etc.), then such video would constitute Subscription AVC Video. In cases where AVC Video is delivered to End Users on a pay-per-view basis, then such content would constitute Title-by-Title AVC Video. If a party offers Subscription or Title-by-Title AVC Video to End Users, then they would be responsible for paying the applicable royalties you noted below.

Finally, in the case where AVC Video is distributed for free through an "over-the-air, satellite and/or cable transmission", then such content would constitute Free Television AVC Video and would be subject to the applicable royalties.

For your reference, I have attached a .pdf copy of the AVC License. You will find the relevant sublicense information regarding AVC Video in Sections 2.2 through 2.5, and the corresponding royalties in Section 3.1.2 through 3.1.4. You will also find the definitions of Title-by-Title AVC Video, Subscription AVC Video, Free Television AVC Video, and Internet Broadcast AVC Video in Section 1 of the License. Please note that the electronic copy is provided for informational purposes only and cannot be used for execution.

I hope the above information is helpful. If you have additional questions or need further assistance with the AVC License, please feel free to contact me directly.

Having a fresh copy of the license text was useful, and knowing that the definition of Title-by-Title required payment per title made me aware that my earlier understanding of that phrase had been wrong. But I still had a few questions:

I have a small followup question. Would it be possible for me to get a license with MPEG LA even if there are no royalties to be paid? The reason I ask, is that some video related products have a copyright clause limiting their use without a license with MPEG LA. The clauses typically look similar to this:

This product is licensed under the AVC patent portfolio license for the personal and non-commercial use of a consumer to (a) encode video in compliance with the AVC standard ("AVC video") and/or (b) decode AVC video that was encoded by a consumer engaged in a personal and non-commercial activity and/or AVC video that was obtained from a video provider licensed to provide AVC video. No license is granted or shall be implied for any other use. additional information may be obtained from MPEG LA L.L.C.

It is unclear to me if this clause mean that I need to enter into an agreement with MPEG LA to use the product in question, even if there are no royalties to be paid to MPEG LA. I suspect it will differ depending on the jurisdiction, and mine is Norway. What is MPEG LAs view on this?

According to the answer, MPEG LA believe those using such tools for non-personal or commercial use need a license with them:

With regard to the Notice to Customers, I would like to begin by clarifying that the Notice from Section 7.1 of the AVC License reads:


The Notice to Customers is intended to inform End Users of the personal usage rights (for example, to watch video content) included with the product they purchased, and to encourage any party using the product for commercial purposes to contact MPEG LA in order to become licensed for such use (for example, when they use an AVC Product to deliver Title-by-Title, Subscription, Free Television or Internet Broadcast AVC Video to End Users, or to re-Sell a third party's AVC Product as their own branded AVC Product).

Therefore, if a party is to be licensed for its use of an AVC Product to Sell AVC Video on a Title-by-Title, Subscription, Free Television or Internet Broadcast basis, that party would need to conclude the AVC License, even in the case where no royalties were payable under the License. On the other hand, if that party (either a Consumer or business customer) simply uses an AVC Product for their own internal purposes and not for the commercial purposes referenced above, then such use would be included in the royalty paid for the AVC Products by the licensed supplier.

Finally, I note that our AVC License provides worldwide coverage in countries that have AVC Patent Portfolio Patents, including Norway.

I hope this clarification is helpful. If I may be of any further assistance, just let me know.

The mentioning of Norwegian patents made me a bit confused, so I asked for more information:

But one minor question at the end. If I understand you correctly, you state in the quote above that there are patents in the AVC Patent Portfolio that are valid in Norway. This make me believe I read the list available from <URL: http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx > incorrectly, as I believed the "NO" prefix in front of patents were Norwegian patents, and the only one I could find under Mitsubishi Electric Corporation expired in 2012. Which patents are you referring to that are relevant for Norway?

Again, the quick answer explained how to read the list of patents in that list:

Your understanding is correct that the last AVC Patent Portfolio Patent in Norway expired on 21 October 2012. Therefore, where AVC Video is both made and Sold in Norway after that date, then no royalties would be payable for such AVC Video under the AVC License. With that said, our AVC License provides historic coverage for AVC Products and AVC Video that may have been manufactured or Sold before the last Norwegian AVC patent expired. I would also like to clarify that coverage is provided for the country of manufacture and the country of Sale that has active AVC Patent Portfolio Patents.

Therefore, if a party offers AVC Products or AVC Video for Sale in a country with active AVC Patent Portfolio Patents (for example, Sweden, Denmark, Finland, etc.), then that party would still need coverage under the AVC License even if such products or video are initially made in a country without active AVC Patent Portfolio Patents (for example, Norway). Similarly, a party would need to conclude the AVC License if they make AVC Products or AVC Video in a country with active AVC Patent Portfolio Patents, but eventually Sell such AVC Products or AVC Video in a country without active AVC Patent Portfolio Patents.

As far as I understand it, MPEG LA believe anyone using Adobe Premiere and other video related software with a H.264 distribution license need a license agreement with MPEG LA to use such tools for anything non-private or commercial, while it is OK to set up a Youtube-like service as long as no-one pays to get access to the content. I still have no clear idea how this applies to Norway, where none of the patents MPEG LA is licensing are valid. Will the copyright terms take precedence or can those terms be ignored because the patents are not valid in Norway?

Categories: Elsewhere

Russ Allbery: INN 2.6.0 release candidate

Planet Debian - Tue, 07/07/2015 - 05:23

In more INN-related news (and catching up on my substantial backlog), a second release candidate for the INN 2.6.0 release is now available. (The first one was only circulated on the inn-workers mailing list.)

INN 2.6.0 is the next major release of INN, with lots of improvements to the build system, protocol support, and the test suite, among many other things. Changes have been accumulating slowly for quite some time.

There are a lot of changes, so I won't go into all the details here. If you're curious, take a look at the NEWS file. You can get the release candidate from ftp.isc.org. (Note that this link will be removed once INN 2.6.0 is released.)

As always, thanks to Julien ÉLIE for preparing this release and doing most of the maintenance work on INN!

For more information about INN, see the official ISC download page or from my personal INN pages. The latter also has links to the full changelog and the other INN documentation.

Categories: Elsewhere


Subscribe to jfhovinne aggregator