Feed aggregator

DrupalCon News: Calling all Systems Engineers and DevOps leads!

Planet Drupal - Tue, 03/02/2015 - 21:33

A developer has just uploaded code that "worked on their machine" to your web site and it brought your company to a screeching halt. What do you do?

If you have answers that help solve this question, then we want YOU at DrupalCon Los Angeles!

Categories: Elsewhere

Drupal core announcements: This Month in Drupal Documentation - January 2014

Planet Drupal - Tue, 03/02/2015 - 20:02

Here's an update from the Documentation
Working Group (DocWG)
on what has been happening in Drupal
Documentation in the last month or so. Sorry... because this is posted
in the Core group as well as Documentation, comments are disabled.

If you have comments or suggestions, please see the DocWG home
for how to contact us. Thanks!

Notable Documentation Updates
  • Work is still ongoing on writing the so-called hook-help texts for
    the Drupal 8 core modules - that are the help texts that are displayed
    by the help module within your site. To help with this, see
    https://www.drupal.org/node/1908570 and find a child issue in the
    sidebar that is still open.
  • Most of this help texts need to be reviewed again, because this
    task started nearly two years ago and in the meantime UI changes have
    been made. An easy way of reviewing these without installing Drupal 8
    locally is to use http://simplytest.me/ to roll out the latest Drupal 8
    dev version. For more detailed information, see

The API reference site, https://api.drupal.org, has recently been updated:

  • The theme is now responsive.
  • Reference links for constants have been added, linking to functions that use the constant: see constant KernelEvents::REQUEST
  • There's a new Events topic for Drupal 8 that already has links to the Symfony event constants in it; more will be coming: see Events
  • Topic pages can now have sub-topics: see Views plugins

See the DocWG page for how to contact us, if you'd like to be listed here in our
next post!

Thanks for contributing!

Since 1 January, 213 contributors have made 601 total page revisions,
including 5 people who made more then 20 edits: lolandese, sidharrell,
satraa,jhodgdon and webchick.

On the weekend 17/18 January, a global sprint weekend took place in
during which we also worked on documentation, working on the hook_help
texts and the install.txt for Drupal 8.

Thank you to everybody who took part!

In addition, there were many many commits to Drupal Core and
contributed projects that improved documentation -- these are hard to
count, because many commits combine code and documentation -- but they
are greatly appreciated too!

Documentation Priorities

The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.

The two meta issues to update and review of help texts
currently have a high priority: Not only do we need them for a good user
experience of Drupal 8, they also need to be translated once they are
Working on them is also a good way to find out already how
Drupal 8 will work for site builders and site administrators.

If you're new to contributing to documentation, these projects may
seem a bit overwhelming -- so why not try out a New contributor
to get started?

Upcoming Events Report from the Working Group

Since there is a re-curring demand for curated documentation, the
Working Group is discussing different option of how best to create and
implement them.
In January, we also had a meeting with staff of the Drupal Association,
to discuss the state of the of improvements on drupal.org to make
documentation and related tasks more user-friendly.

Categories: Elsewhere

Conocimiento Plus: What Google Code-In and Drupal meant to me

Planet Drupal - Tue, 03/02/2015 - 18:24
The more I learn, the more I realize how much I don’t know. - Albert Einstein Background I was thirteen when I first got access to a computer, I had no idea about how to connect to internet and when I was fourteen I had watched a documentary about Google and discovered that there was […]
Categories: Elsewhere

Lullabot: Understanding JavaScript behaviors in Drupal

Planet Drupal - Tue, 03/02/2015 - 18:00

I can barely remember the first time I added JavaScript to a Drupal page using a custom module. I'm sure looked at the documentation, took the example snippet, tweaked it, tested it, and moved on to something else. It was only later, using a debugger, that I saw how Drupal's "behavior" system worked and realized that my code was not being executed as I expected.

In this article, we'll cover the key facts about Drupal behaviors, then look at a real Drupal project to inspect its behaviors and optimize them.

Categories: Elsewhere

Localize.drupal.org: Time to start translating Drupal 8!

Planet Drupal - Tue, 03/02/2015 - 17:33

Drupal 8 is in the beta releases stage getting closer to supporting an upgrade path. It is still in development and there are still some interface changes expected. As per the beta changes policy interface string are unfrozen and user experience improvements are prioritized. On the other hand, I don't know of major initiatives to change the interface strings and I believe most of the interface should be considered stable at this point.

As we are getting close to releasing beta versions with support for the upgrade path, that means more sites will start to use pre-release versions of Drupal 8. This helps find bugs and we would love the multilingual system to be (even more) thoroughly tested as well. We need translations for that to happen. We also need translators to look at source strings, so they submit issues found in them.

So while the user interface is not yet frozen, there are various good reasons to start translating Drupal 8 now. How fast should you plan to complete translations? Strings will likely be frozen with the first release candidate (which is cut when there are no more critical issues against Drupal 8). However that release candidate may become a release if no more critical issues found as early as a couple weeks after, so starting translation at RC1 would be too late to be ready for the release. You should consider starting sooner than later.

To make that process easier, we introduced a new Drupal 8 translation status page at https://localize.drupal.org/translate/drupal8 which lists the languages by completion status based on the last exported Drupal 8 translations available. Congratulations to the Spanish, Danish and Finnish team for being the top three! We also made it easy to access the multilingual demo from that page and included some advice on translation readyness as well as a step by step guide to new contributors.

You are encouraged to start translating Drupal 8, organize local translation sprints and test your translations by installing the new version in your own language. Big Drupal events like DrupalCon Bogota host multiple days of sprints where translators should join and take their space. The next big event coming up in Europe is Drupal Dev Days in April with a week of sprints.

All of the new Drupal 8 APIs should be supported now on the site including default shipped configuration. If you find something on the Drupal 8 user interface that is not translatable, submit a Translation template extractor issue and tag with "Drupal 8 compatibility".

Balu Ertl collected a list of 1200 "easy" Drupal 8 strings to translate to your language. These are 1, 2, 3 or 4 words long.

One final tip to get started faster. Localize.drupal.org does not (yet) support matching of strings that slightly changed from Drupal 7, however it brings in exact translations of modules that were added to core, such as Views. To match slightly changed strings, you can do the following:

  1. Download the complete Drupal 7 translation of your language.
  2. Using the Export tab on your language, export a full translation template (with untranslated and translated strings included) of Drupal 8.
  3. Use the gettext msgmerge tool to find fuzzy matches locally.
  4. Review and correct the translations locally.
  5. Finally import the new translations to the site with the "Multiple contributors" user for proper attribution.

Thanks for making Drupal 8 happen!

read more

Categories: Elsewhere

Aten Design Group: Responsive Images in Drupal: Part 1

Planet Drupal - Tue, 03/02/2015 - 17:17

Solid imagery can make or break a design. In our current world of changing screen sizes, screen resolutions, and bandwidth the effective use of imagery has not only become more important, but a lot more challenging.

You may want to serve up a scaled-down image in an effort to optimize performance. You may want a scaled-up image to optimize for high resolution devices. Or you may want to serve the same image, cropped differently to work better with layout changes at different breakpoints. HTML5’s ‘picture’ element addresses these challenges, and so many more.

Using Drupal, we can automate the creation of the needed versions of a single image, making content creation that much easier. In part 2 we’ll look at opening up control over the art direction of the images, while still maintaining the design’s layout rules.

Setting up the image stack

First we need to create the image styles for our breakpoints. We have three contexts to plan for; small, medium, and large displays. There should be an image style for each, and for now it should have a Scale and Crop effect set to our dimensions.

Setting up Breakpoints

Drupal needs to be made aware of the breakpoints our site uses, and the Breakpoints module does just that. Install Breakpoints and its dependency, CTools. The Breakpoints module has two ways to define breakpoints, in the interface or in your site theme’s .info file. We’ll use the interface (admin/config/media/breakpoints) to create three breakpoints.

Next you need to create a Breakpoint Group (admin/config/media/breakpoints/groups/add). Imagine you have several more breakpoints defined, but you want to pick specific ones to apply to one component of the site. With Breakpoint Groups, you have that ability.

Setting up the Picture module

While the Breakpoints module handles the definition and organization of breakpoints, the Picture module uses Breakpoint Groups to create the markup. Enable the Picture module and add a new Picture Mapping (admin/config/media/picture).

After you’ve chosen your Breakpoint Group, you’ll have some options as to what should happen at each breakpoint. In our case we want to match each breakpoint up to the appropriate image style we created earlier.

Applying this to an image field

Once all this has been set up, we can now use our Picture Mapping as a field formatter for an image field on the site. Visit the Manage Display tab for a content type with an image field, and set the Format to the Picture Mapping we set up.

One important thing to notice is the Fallback Image Style. This is what image will be used in browsers that do not support media queries.

Wrapping up

If you create a piece of content, the rendered image should get switched out if you view the full node and resize the window. The only downside to this is Drupal is deciding what the focal point of the image is, which may not always be desirable. In the next part of this tutorial, we’ll look at using the Manual Crop module in order to give that control back to content editors.

Categories: Elsewhere

EchoDitto Tech Blog: Rapid Drupal Scaffolding with Yeoman

Planet Drupal - Tue, 03/02/2015 - 17:06

Simple things should be simple, complex things should be possible.

– Alan Kay

The Console module in Drupal 8 has a lot of developers excited, seeing as it has built in support for scaffolding out and generating modules at the command line. This particular feature will put Drupal in line with some of the other more MVC-like frameworks out there, like Ruby on Rails or Laravel, which both have a suite of supporting libraries that take some pain out of development by generating reliable boilerplate code.

This is all well and good, but what about Drupal 7? The Drupal 8 release date may still be a bit far off, and even then many Drupal 7 sites will still need maintaining, as a lot of contrib modules will be slower still to make the complete switch. Yet, we can have our proverbial cake and eat it too. Yeoman is a language-agnostic scaffolding framework which relies on Node.js. By allowing the user of the generator to input specific variables to fit their needs, it gives you the flexibility of creating best-practices code on the fly, while still being unique to a specific use-case.

One Yeoman generator in particular that's proven particularly useful is Drupal Entities, which allows for rapid creation of Entities, i.e. the underlying class for Nodes, Content Types, and so on. It also proved to be an excellent example of how to make a Drupal-specific version of a generator—and was good inspiration to locate other common custom Drupal development tasks that could have their complexity mitigated. One common use case I've run into is creating custom Field and Views Formatters, in particular integrating a jQuery plugin to the output of a Views list or multivalued-field, while still preserving the formatter settings. Thus began my hacking.

We are already big fans of the Owl Carousel Module here at Echo, which is a fantastic integration of the Owl Carousel jQuery plugin with Drupal, and is utilized on a number of our sites. It not only provides Field and Views formatters, but also unlimited settings groups (controlling, e.g., speed, width and number of items in each carousel), which are dynamically assigned to variables in the DB, and then can be loaded individually in any number of instances on the front-end of the site (if you had more than one carousel on a page, for instance). To me, this presented the perfect architecture to make a generic version to use as a template for integrating other JavaScript plugins.

Essentially, the structure of the code that one makes generic to work with Yeoman mirrors the directory of the actual application/module, so in this case our file structure is incredibly familiar. Aside from our .json configuration files, you'll see our app directory (where the templates live) is loaded with some familiar Drupal file extensions: .module, .info, .install, etc.

We also have theme, submodule modules and includes directories which house more of these underscore-prefaced templates, which are essentially PHP files that Yeoman treats as plain text files. After the user is prompted for a number of values, (in this case, the name of the module, the name of the plugin being integrated, and some meta-information about the settings--i.e., whether it is a boolean, integer, or string), Yeoman traverses the templates, finding and replacing any reference to those variables, which are delimited by templating tags. Here's an example hook in one of these files with several variables that will be replaced by the user supplied values on the command line:

<?php   /** * Implements hook_library(). */ function <%= moduleName %>_library() { $library = libraries_get_path('<%= libraryName %>');   $libraries['<%= pluginName %>'] = array( 'title' => '<%= pluginProper %>', 'website' => '<%= pluginSite %>', 'version' => array(), 'js' => array( $library . '<%= relativeScriptpath %>' => array( 'scope' => 'footer', ), ), 'css' => array( $library . '<%= relativeStylepath %>' => array( 'type' => 'file', 'media' => 'screen', ), ), );   return $libraries; }

So after paring the module down to its core and assuring every value was being dynamically populated, I tested out whether it all came together by generating a Module that integrates a JS plugin called oriDOMi. The result was that I only needed to perform maybe a half an hour of debugging—simply fixing the initialization method in the JavaScript so that it was calling on the correct nested JSON object settings group. Of course, many hours were spent getting the generator ready, but essentially this lays the groundwork to let developers focus on enhancing the front-end integrations they're doing, as opposed to worrying about how a client or even another developer will manage the inevitable need to change something as trivial as how fast something should animate. The resulting module is available online, if you'd like to see what the output looks like here.

Here's is a bonus pic of the result of that particular test generation:

Placeholder text generated from Gluten Ipsum.

The entire source of the generator itself is available at GitHub, where you can peruse the code. You'll find installation and usage instructions as well, and as always, if you've found something that could be improved, please fork and make a pull request! Additionally, an in depth guide to making your own generators for Drupal may be on the way—but until then, the documentation for Yeoman is a wonderful starting point.

Tags: codeyeomandrupalgeneratornode.jsphpmvcconsolecliyonpmmodule
Categories: Elsewhere

Tag1 Consulting: How to Maintain Contrib Modules for Drupal and Backdrop at the Same Time

Planet Drupal - Tue, 03/02/2015 - 16:26
Part 1 - Reuse the Same Code

In mid-January, the first version of Backdrop CMS was released. Backdrop is a fork of Drupal that adds some highly-anticipated features and API improvements to the core Drupal platform while focusing on performance, usability, and developer experience.

read more

Categories: Elsewhere

Thorsten Alteholz: USB 3.0 hub and Gigabit LAN adapter

Planet Debian - Tue, 03/02/2015 - 15:18

Recently I bought an USB 3.0 Hub with three USB 3.0 ports and one Gigabit LAN port. It is manufactured by Delock and I purchased it from Reichelt (Delock 62440).

Under Wheezy the USB part is recognized without problems but the kernel (3.2.0-4) does not have a driver for the ethernet part.
The USB Id is idVendor=0b95 and idProduct=1790, the manufacturer is ASIX Elec. Corp. and the product is: AX88179. So Google led me to a product page at Asix, where I could download the driver for kernel 2.6.x and 3.x.

mkdir -p /usr/local/src/asix/ax88179
cd /usr/local/src/asix/ax88179
wget www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE.tar.bz2
tar -jxf AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE.tar.bz2
cd AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE
apt-get install module-assistant
module-assistant prepare
make install
modprobe ax88179_178a.ko

After editing /etc/network/interfaces and doing an ifup eth1, voila, I have a new network link. I hope the hardware is as good as the installation has been easy.

Categories: Elsewhere

Sjoerd Simons: Debian Jessie on Raspberry Pi 2

Planet Debian - Tue, 03/02/2015 - 11:24

Apart from being somewhat slow, one of the downsides of the original Raspberry Pi SoC was that it had an old ARM11 core which implements the ARMv6 architecture. This was particularly unfortunate as most common distributions (Debian, Ubuntu, Fedora, etc) standardized on the ARMv7-A architecture as a minimum for their ARM hardfloat ports. Which is one of the reasons for Raspbian and the various other RPI specific distributions.

Happily, with the new Raspberry Pi 2 using Cortex-A7 Cores (which implement the ARMv7-A architecture) this issue is out of the way, which means that a a standard Debian hardfloat userland will run just fine. So the obvious first thing to do when an RPI 2 appeared on my desk was to put together a quick Debian Jessie image for it.

The result of which can be found at: https://images.collabora.co.uk/rpi2/

Login as root with password debian (Obviously do change the password and create a normal user after booting). The image is 3G, so should fit on any SD card marketed as 4G or bigger. Using bmap-tools for flashing is recommended, otherwise you'll be waiting for 2.5G of zeros to be written to the card, which tends to be rather boring. Note that the image is really basic and will just get you to a login prompt on either serial or hdmi, batteries are very much not included, but can be apt-getted :).

Technically, this image is simply a Debian Jessie debootstrap with a extra packages for hardware support. Unlike Raspbian the first partition (which contains the firmware & kernel files to boot the system) is mounted on /boot/firmware rather then on /boot. This is because the VideoCore expects the first partition to be a FAT filesystem, but mounting FAT on /boot really doesn't work right on Debian systems as it contains files managed by dpkg (e.g. the kernel package) which requires a POSIX compatible filesystem. Essentially the same reason why Debian is using /boot/efi for the ESP partition on Intel systems rather the mounting it on /boot directly.

For reference, the RPI2 specific packages in this image are from https://repositories.collabora.co.uk/debian/ in the jessie distribution and rpi2 component (this repository is enabled by default on the image). The relevant packages there are:

  • linux: Current 3.18 based package from Debian experimental (3.18.5-1~exp1 at the time of this writing) with a stack of patches on top from the raspberrypi github repository and tweaked to build an rpi2 flavour as the patchset isn't multiplatform capable
  • raspberrypi-firmware-nokernel: Firmware package and misc libraries packages taken from Raspbian, with a slight tweak to install in /boot/firmware rather then /boot.
  • flash-kernel: Current flash-kernel package from debian experimental, with a small addition to detect the RPI 2 and "flash" the kernel to /boot/firmware/kernel7.img (which is what the GPU will try to boot on this board).

For the future, it would be nice to see the Raspberry Pi 2 support out of the box on Debian. For that to happen, the most important thing would be to have some mainline kernel support for this board (supporting multiplatform!) so it can be build as part of debians armmp kernel flavour. And ideally, having the firmware load a bootloader (such as u-boot) rather than a kernel directly to allow for a much more flexible boot sequence and support for using an initramfs (u-boot has some support for the original Raspberry Pi, so adding Raspberry Pi 2 support should hopefully not be too tricky)

Categories: Elsewhere

Thomas Goirand: OpenStack packaging activity, November 2014 to January 2015

Planet Debian - Tue, 03/02/2015 - 11:15

November 2014:
Sunday 2nd:
– Travel from Moscow to Paris

Monday 3rd to Sunday 8th:
– Summit in Paris

Monday 10th:
– Uploaded python-rudolf to Sid (needed by Fuel)
– Uploaded python-invoke and python-invocations (needed to run fabric’s unit tests)
– Uploaded python-requests-kerberos/0.5-2 fixing CVE-2014-8650: failure to handle mutual authentication. Asked the release team for unblock.
– Uploaded openstack-pkg-tools version 19 fixing startup with systemd in Jessie (added RuntimeDirectory directive). Asked the release team for unblock.
– Opened ticket to remove TripleO, Tuskar and Ironic packages from Jessie. I don’t consider them ready for a Debian stable release, and there’s no long term support from upstream.
– Fixed Designate Juno dbsync process which prevented it from being installed.
– Fixed Ironic Juno unowned files after purge (policy 6.8, 10.8): /var/lib/ironic/{cache, ironicdb} (eg: purging these folders on purge)

Thuesday 11:
– Fixed nova-api “CVE-2014-3708: Nova network DoS through API filtering” in both the Juno and Icehouse release. Asked the release team to unblock the Icehouse version for Jessie. See: https://bugs.debian.org/769163
– Uploaded Cinder with Duch debconf translation fix and pt.po
– Uploaded python-django-pyscss with upstream patch for Django 1.7 support instead of the Debian one that I wrote 2 months ago. Asked the release team to unblock which they did.

Wednesday 12:
– Uploaded fix for horizon (see #769101) unowned files after purge (policy 6.8, 10.8). Now purging /usr/share/openstack-dashboard/openstack_dashboard on purge.
– Uploaded Ironic with Duch translations of debconf
– Uploaded Designate with Duch translations of Debconf screens
– Uploaded openstack-trove with Duch translations of Debconf screens
– Uploaded Tuskar with Duch translations of Debconf screens
– Updated python-oslotest in Experimental to version 1.2.0

Thursday 13:
– Uploaded new packages: python-oslo.middleware and python-oslo.concurrency.
– Opened a new packaging branch for Nova Kilo, and updated (build-)depends.
– Uploaded fix for Icehouse Cinder: “delete volume failed due to unicode problems”, and asked for unblock.
– Uploaded new package: python-pygit2 and python-xmlbuilder, needed for fuel-agent-ci.
– Uploaded sheepdog with Duch debconf translation.
– Uploaded python-daemonize to Sid (in FTP master NEW queue).
– Re-uploaded python-invoke after FTP master rejection (missing copyright information)

Friday 14:
– Uploaded liberasurecode & python-pyeclib to Sid, now in the FTP masters NEW queue waiting for approval. This will soon be needed by Swift.

Monday 17:
– Worked on the Cobbler packaging (all day long…)

Tuesday 18:
– Worked on backporting all of Fuel packages to Wheezy. Done with fuelclient already.
– Uploaded ruby-cstruct and ruby-rethtool to Sid (needed by nailgun-agent)

Wednesday 19:
– Uploaded pyeclib again, with fixes for the build-depends. Package is still in the NEW queue anyway.
– Built a Debian-based bootstrap hardware discovery image for Fuel, and … it seems that it works already (to be checked…)! \o/
To be added as packages in the ISO:
* nailgun-mcagents
* nailgun-net-check
* fuel-agent
* python-tasklib

Thursday 20:
– Uploaded python-tasklib to Sid (now in NEW queue…)
– Continued working on the discovery bootstrap ISO

Friday 21:
– Documented Sahara procedure in Debian in the official install-guide: https://review.openstack.org/136237
– Fixed oslo.messaging so it doesn’t use PROTOCOL_SSLv3 because its support has been removed from Debian (due to possible protocol downgrade attacks): https://review.openstack.org/136278 and uploaded fixed packages for Sid and Experimental.
– Uploaded fixed Neutron packages for CVE-2014-7821 in both Sid and Experimental (eg: Icehouse and Juno)

Monday 24:
– Uploaded new package: python-os-client-config (in NEW queue)
– Installed new Xen server to be used as my new Jenkins build machine
– Moved the juno-wheezy VM to it
– Finished to package python-pymysql and uploaded to Sid. It’s now running all unit tests successfully! \o/

Tuesday 25:
– Uploaded fix for openstack-debian-images to add the -o compat=1.0 option when building an image with Qemu > 1.0. Opened bug to the release team to have it unblocked.
– Continued working on unit tests for fuel-nailgun.

Wednesday 26:
– Uploaded python-os-net-config to Sid (new package)
– Worked briefly on python-cassandra-driver. It needs cassandra to be in, which is a LOT of work.
– Found a (not useable) hack to run nailgun unit tests. It works, however, it doesn’t seem like fuel-nailgun is designed to be able to use unix socket for the postgres connection in its unit tests.
– Uploaded python-pykmip to Sid (new package)
– Updated the Debian wheezy backport repository for libvirt to version 1.2.9 from official wheezy-backports. Removed policykit-1 and libusb from there too, as it broke stuff to use a backported version (X and usb were not useable on my Wheezy laptop when using it…).

Thursday 27 & Friday 28:
– Uploaded new Javascript packages or dependencies for Fuel: libjs-autonumeric, libjs-backbone-deep-model, libjs-backbone.stickit, libjs-cocktail, libjs-i18next, libjs-require-css, libjs-requirejs, libjs-requirejs-text

Sunday 30:
– Uploaded debian/copyright fixes for libjs-backbone-deep-model, libjs-backbone.stickit and libjs-cocktail after the packages were accepted by the FTP masters and they gave remarks about copyright.


Monday 01:
– Uploaded new Debian image to MOX, after I unerstood the issue was about the architecture field that I was wrongly filling. I’ll be able to use that for Tempest checking on my dev account.

Tuesday 02:
– Uploaded python-q-text-as-data to Sid (new awesome package!)
– Uploaded Horizon with some triggers mechanisms to start the compress when one of its JS depends is updated. That’s very important for security!
– Uploaded a fixed version of heat-cfntools to Sid (it was missing the /usr/lib/python* folder). Asked the release team for an unblock so it can reach Jessie.
– Fixed unit tests in fuel-nailgun, thanks to a patch from Sebastian Kalinowski. Now all unit tests are passing but one (for which I opened a launchpad bug: tests are trying to write in /var/log/nailgun, which is impossible at package build time).

Wednesday 03:
– Uploaded fixed version of ruby-rethtool after FTP master’s rejection and upstream correction of licensing files.
– Uploaded fixed version of libjs-require-css after FTP master’s rejection
– Fixed (in Git only) python-sysv-ipc missing build-depends on dh-python as per bug opened by James Page (this is not so important, but I did it still).
– Continued working on the tempest-ci scripts.
– Added to the image-guide docs about openstack-debian-images: https://review.openstack.org/#/c/138743/

Thursday 04:
– Uploaded new package: python-proliantutils. Send patch to upstream about an issue in indentation (mix-up with space and tabs) which made the package uninstallable with Python 3.4.

Friday 05:
– Worked on the package CI.

Monday 07:
– Worked on the package CI. All works now, up to all of the Tempest tests for Keystone. Now need to fix the neutron config.

Thuesday 08:
– Continued working on the CI.

Wednesday 09:
– Uploaded fix for FTBFS of python-tasklib (Closes: #772606)
– Uploaded fix for libjerasure-deb missing dependency on libgf-complete-dev, package already unblocked and will migrate to Jessie.
– Uploaded fix for Designate Juno fail to upgrade from Icehouse: this was due to the database_connection directive renamed to connection =.
– Uploaded fix for Designate purge in Sid (Icehouse release of Designate).
– Commited to git updates of the German debconf translation in both Icehouse and Juno.
– Updated nova to use libvirtd as init script dependency instead of libvirt-bin (this was renamed in the libvirt-daemon-system package).
– Do not touch the db connection directive if user didn’t ask for db handling by the package.

Thursday 10 to Saturday 13:
– Finally understood the issues with systemd service files not being activated by default. Fixed openstack-pkg-tools, and uploaded version 20 to Sid, after the release team accepted the changes.

Sunday 14:
– Uploaded Juno 2014.2.1 to Experimental: ceilometer, cinder, glance, python-glance-store, heat, horizon, keystone

Monday 15:
– Finished uploading Juno 2014.2.1 to Experimental: Nova, Neutron, Sahara

Tuesday 16:
– Added crontab to flush tokens in Icehouse Keystone
– Some more CI work

Wednesday 17:
– Uploaded keystone with systemd fix and crontab to flush the token table in Sid (eg: Icehouse).
– Uploaded nova Icehouse with a bunch of fixes in Sid.

Thursday 18:
– Updated some issues in Nova Icehouse (Sid/Jessie)

Friday 19:
– Started building a new Jenkins instance for building Kilo packages

Monday 22:
– Finished building the new Jenkins instance for building Kilo packages, and rebuilt every packages there, using Jessie as a base.

Tuesday 23:
– Updated version for the following packages: oslo.utils, oslo.middleware, stevedore, oslo.concurency, pecan, oslo.concurrency, python-oslo.vmware, python-glance-store
– Built so far: Ceilometer, Keystone, python-glanceclient, cinder, glance

Wednesday 24:
– Continued packaging Kilo beta 1. Updated: nova, designate, neutron
– Uploaded python-tempest-lib to Debian Unstable (new package)

Wednesday 31:
– Continued packaging Kilo beta 1. Updated: heat


Thursday 01:
– Continued packaging Kilo beta 1. Updated: ironic, openstack-trove, openstack-doc-tools, ceilometer

Friday 02:
– Finished packaging Kilo beta 1. Updated: Sahara, Murano, Murano-dashboard, Murano-agent

Sunday 04:
– Started testing Kilo beta 1. Fixed a few issues on default configuration for Ceilometer and Glance.

Monday 05:
– Fixed openstack-pkg-tools which failed to create PID files at boot time, Uploaded to Sid, asked the release team for unblock.
– Uploaded ceilometer & cinder to Sid, rebuilt against openstack-pkg-tools 21.
– Did more testing of Kilo beta 1, fixed a few more minor issues.

Tuesday 06:
– Uploaded glance, neutron, nova, designate, keystone, heat, trove to Sid, so that all sysv-rc init scripts are fixed with the new openstack-pkg-tools 21. Designate, heat, keystone and trove contains other minor fixes reported to the Debian BTS.

Wednesday 07:
– Asked the Debian release team (open bugs with debdiff as attachment) for unblocks of glance, neutron, nova, designate, keystone, heat, trove so they migrate to Jessie.
– Fixed a few minor issues tracked in the Debian BTS on various packages.

Thesday 08:
– James Page from Canonical informed me that they are now using openstack-pkg-tools for maintaining their daemons in Nova, Cinder and Keystone in Ubuntu. That’s an awesome news : more QA for both platforms.
– James Page found out that dh_installinit *must* be called *after* the call of dh_systemd_enable, otherwise, daemons aren’t started automatically at the first install of packages, as the unmask of systemd happens after the invoke-rc.d.

Friday 09:
– Did some QA checks on the latest upload. Fixed Heat which broke because using the wrong template name (glance instead of heat).

Monday 12:
– Started re-running the automated openstack-deploy scrip in Icehouse, Juno and Kilo. Found out the issue in Keystone wasn’t fixed in Juno (but was fixed in other releases), and fixed it.
– Removed the use of ssl.PROTOCOL_SSLv3 from heat (removed form Debian). Uploaded the fixed package to Sid.
– All of openstack-deploy (debian/kilo branch) now works and succesfully installs OpenStack again.

If dh_installinit is called before, we have:

# Automatically added by dh_installinit if [ -x "/etc/init.d/keystone" ]; then update-rc.d keystone defaults >/dev/null fi if [ -x "/etc/init.d/keystone" ] || [ -e "/etc/init/keystone.conf" ]; then invoke-rc.d keystone start || true fi # End automatically added section # Automatically added by dh_systemd_enable # This will only remove masks created by d-s-h on package removal. deb-systemd-helper unmask keystone.service >/dev/null || true # was-enabled defaults to true, so new installations run enable. if deb-systemd-helper --quiet was-enabled keystone.service; then # Enables the unit on first installation, creates new # symlinks on upgrades if the unit file has changed. deb-systemd-helper enable keystone.service >/dev/null || true else # Update the statefile to add new symlinks (if any), which need to be # cleaned up on purge. Also remove old symlinks. deb-systemd-helper update-state keystone.service >/dev/null || true fi # End automatically added section

If it’s called after dh_systemd_enable, we have:

# Automatically added by dh_systemd_enable # This will only remove masks created by d-s-h on package removal. deb-systemd-helper unmask keystone.service >/dev/null || true # was-enabled defaults to true, so new installations run enable. if deb-systemd-helper --quiet was-enabled keystone.service; then # Enables the unit on first installation, creates new # symlinks on upgrades if the unit file has changed. deb-systemd-helper enable keystone.service >/dev/null || true else # Update the statefile to add new symlinks (if any), which need to be # cleaned up on purge. Also remove old symlinks. deb-systemd-helper update-state keystone.service >/dev/null || true fi # End automatically added section # Automatically added by dh_installinit if [ -x "/etc/init.d/keystone" ]; then update-rc.d keystone defaults >/dev/null fi if [ -x "/etc/init.d/keystone" ] || [ -e "/etc/init/keystone.conf" ]; then invoke-rc.d keystone start || true fi # End automatically added section

As a consequence, I have to re-upload version 22 of openstack-pkg-tools and also re-upload all OpenStack core packages to Debian Sid.

– Fixed a number of issues like:
* dbc_upgrade = true check which shouldn’t have been there in postinst.
* <project>/configure_db default value is now always false
* db_sync and pkgos_dbc_postinst are now only done if <project>/configure_db is set to true.
– Rebuilt all packages in Juno and Kilo with the above changes.

Tuesday 13:
– Opened unblock bugs for the release team to unblock all fixed packages.
– Made more tests in Juno and Kilo to make sure the fixed bugs in Icehouse are fixed there too.
– Fixed numerous issues in Trove (missing trove-conductor.conf, wrong trove-api init file, etc.). More work will be needed for it for both Icehouse and newer releases.

Wednesday 14:
– Did a doc meeting about debconf. Some doc contributors still want to kill the debconf / debian manual, and I have to not agree.
– Made a new patch to better document the keystone install procedure:
– Did some bug triaging in the doc about Debian.
– Uploaded new versions of core packages to Experimental (eg: Juno) built against openstack-pkg-tools >= 22~, and some fixes forward ported from Icehouse: Keystone, Ceilometer, Cinder, Glance, Heat, Ironic, Murano, Neutron, Nova, Saraha and Murano-agent. All where rebuilt in Juno (Wheezy + Trusty) and Kilo (Jessie only) on my Jenkins.

Thuesday 15:
– Succesfully booted a live-build Debian live image containing mcollective and nailgun-agent as a Debian replacement for the hardware discovery / boostrap image of Fuel. Now, I need to find a way to use just a kernel + initramfs

Friday 16 to Tuesday 20:
– Worked on the packaging CI.

Wednesday 21:
– Fixed https://bugs.debian.org/775636 (Horizon failed to build due to a Moscow timezone change and wrong test). Uploaded to Sid, asked for unblock.
– Fixed https://bugs.debian.org/775926: CVE-2015-1195: Glance still allows users to download and delete any file in glance-api server (applied upstream patch). Uploaded to Sid, asked for unblock. Uploaded Juno version to Experimental.
– Uploaded openstack-trove with the remaining fixes, asked release team for unblock.
– Uploaded python-glanceclient 0.15.0 (Juno) to Experimental because it fixes an issue with HTTPS. Added to it a patch from James Page not yet merged, which fixes unit test with Python 2.7.9 (7 failures otherwise).
– Uploaded python-xstatic-d3 as it can’t be installed anymore in Sid after a new version of d3 was uploaded.

Thursday 22:
– Uploaded python-xstatic-smart-table and libjs-angularjs-smart-table to Sid (new packages, now in NEW queue).

Friday 23:
– Ask for the removal of the below list of packages from Jessie:

They are used only in OpenStack Horizon starting on 2014.2 (aka Juno), and Jessie is shipped with Icehouse, so it’s IMO best to not carry the burden of maintaining these packages for the life of Jessie.

Monday 26:
– Enhanced and review requested changes for https://review.openstack.org/147296 (ie: Keystone install with more details about what the package does).
– Finished testing network on the CI install. Now need to automate all.

Tuesday 27:
– Closed all bugs on the rabbitmq-server package (2 correction, one bug triage).
– Uploaded a fix for the missing conntrack dependency in neutron-l3-agent.
– Restarted working on CI setup of Juno after success with manual install in a Xen domU.
– Uploaded fix to make sheepdog build reproducible (patch from the Debian BTS).

Thursday 28:
– Fixed and uploaded to Sid openstack-debian-images 2 bugs reported by Steve McIntire. Official Debian images for OpenStack are now available at:
http://cdimage.debian.org/cdimage/openstack/ \o/
Note that this is the weekly build of testing. We wont get Debian Stable images before Jessie is out.
– Documented the new image thing here: http://docs.openstack.org/image-guide/content/ch_obtaining_images.html#debian-images as a new patch: https://review.openstack.org/#/c/151015/
– Fixed my patch for keystone debconf doc at: https://review.openstack.org/#/c/147296/

Wednesday 29:
– Continued working on packaging CI

Thursday 30:
– Fixed CVE on Neutron (Juno): L3 agent denial of service with radvd 2.0+
– Fixed CVE on Glance (Icehouse + Juno): Glance user storage quota bypass. Asked release team for unblock.
– Fixed the image-guide patch after review (ie: https://review.openstack.org/151015)

Categories: Elsewhere

Mike Hommey: Looking for a new project name for git-remote-hg

Planet Debian - Tue, 03/02/2015 - 11:07

If you’ve been following this blog, you know I’ve been working on a (fast) git remote helper to access mercurial without a local mercurial clone, with the main goal to make it work for Gecko developers.

The way git remote helpers work forces how their executable is named: For a foo:: remote prefix, the executable must be named git-remote-foo. So for hg::, it’s git-remote-hg.

As you may know, there already exists a project with that name. And when I picked the name for this new helper, I didn’t really care to find a separate name, especially considering its prototype nature.

Now that I’m satisfied enough with it that I’m close to release it with a version number (which will be 0.1.0), I’m thinking that the confusion with the other project with that name is not really helpful, and an unfortunate implementation detail.

So I’m looking for a new project name… and have no good idea.

Dear lazy web, do you have good ideas?

Categories: Elsewhere

Károly Négyesi: The brutal truth about security

Planet Drupal - Tue, 03/02/2015 - 03:00

I have cared a lot, even too much about designing secure APIs for Drupal. To create a software which made it easy to write secure custom code and hard to write insecure. I placed this in front of other concerns including developer and user experience. Sounds nice, isn't it? But in truth, I was trying to tend a garden in the nuclear winter. By and large the Internet is so insecure that making it slightly easier to write more secure code is a trifling concern. It is enough that Drupal is not a house of cards of security wise and indeed it is not. Let other concerns win over security in API design. I was wrong. And I am out.

Categories: Elsewhere

CivicActions: Backdrop CMS: A Drupal 8 Alternative

Planet Drupal - Tue, 03/02/2015 - 01:30

There's a lot of excitement about Drupal 8 and it's imminent release. There's also a lot of angst. Yes, Drupal 8 is super slick and full of frameworky, object oriented coolness. The thing is, a lot of people have invested a lot of time learning how to do things in Drupal 7, and the idea of learning how to do things in Drupal 8 can be pretty daunting. This is where Backdrop aims to step in and serve developers and end-users who want to continue doing things mostly the Drupal 7 way, but not fall behind the new technology (or product support) curve.

So what motivated this fork in early D8 development?

Drupal 7 took some time to take hold - there were several reasons for this:

1) D7 is different enough from D6 that it took a considerable investment of time and money to learn (it was more enterprise focused).

2) D7 is often times more abstracted than D6. E.g.: The Commerce suite of modules is extremely powerful, and is considered by most Drupal developers to be the defacto solution for ecommerce, but it is more of a construction kit than a fully asembled product. Whereas, in D6, Ubercart is the way to go for ecommerce, which is pretty close to being fully functional right out of the box. The Commerce vs. Ubercart example serves to highlight the differences in approach between the two.

3) Somewhere along the way from D6 to D7, Drupal stopped being a community filled with people of all skill sets, and more of an elite dev community. This is great, but leads to some interesting challenges. First, it causes a talent shortage - some smaller outfits only require an entry level to mid level Drupal dev (we have all heard about the shortage of Developers available for hire - it's more accurate to say there is a shortage of non-elite level employees for hire). Second, a talent pool comprised of only elite level devs means that the limited talent available to do Drupal work will command a higher price point. This makes Drupal more expensive to implement, and often precludes businesses that would otherwise consider it as a web solution.

Backdrop has a well defined philosophy.

The first and most defining tenet of which is to serve small businesses, non-profits, schools or just any organization that doesn't have a big budget. By continuing to use most of the now familiar D7 api, Backdrop lets devs work with and extend what they already know, thereby lessening the talent pool strain which in turn leads to more affordable web development solutions.

A second tenet of the Backdrop philosophy is that it should be easy to use. Site builders who don't have coding experience should be able to use it without a lot of ramp up time.

A third tenet of the Backdrop philosophy is that contrib developers should be valued over core developers. The idea here being that the more hands there are in core (and focus on core development), the more potential for wonkyness awaits module developers who will be trying to hook into an api in constant flux.

A fourth tenet is that backdrop should be low resource. Speaking from a package size perspective, the most recent version of D8 beta has a 17.2 MB package, whereas Backdrop is 3.9MB.

Lastly, and perhaps the most notable tenet of the Backdrop philosophy, is that they are committed to releases being well planned, small, and on time. These have all proven to be a struggle for D8.

So, how is it different from D7?

Side by side, Backdrop and D7 look a lot alike: both come with the default Bartik and Seven themes, and the same default content types. Looking a little more closely, there are enhancements to Backdrop that help get things moving a little more quickly.

1) A dropdown admin menu with sensible options comes baked in.

2) The annoying admin overlay is gone.

3) All themes are fully responsive.

4) Backdrop comes stock with "Layouts", which I would kind of liken to a scaled down, much lighter weight version of panels, with a much more intuitive, simplified ui, but is still very powerful.

5) Blocks are a lot smarter. They have selection rules that when combined with Layouts, enhance the Panels like experience, but with a learning curve soft enough to make a novice developer productive quickly.

6) Configuration Managment! Sick and tired of confusing features conflicts? Yeah, me too. Configuration management is a breeze to use, and makes migrating database / config settings from server instances fast and easy.

How is Backdrop extended? Just like in D7 = with modules.

There are already a few that have been ported over from D7, but creating a new Backdrop module is almost the same as a creating one in D7 (it's pretty much just a difference in namespacing), and all of the coding conventions and hooks appear to be the same. For example, Backdrop doesn't come with any kind of wysiwyg functionality, and I wanted one with a local install I created, so I went to Drupal.org, downloaded the Ckeditor module and the corresponding js library, installed it, and made one change to the .info file, where core was defined as 7.x: I removed this line and replaced with "backdrop = 1.x." After doing this, Ckeditor was available, and I was able to use it. This is possible because Backdrop has a convenient conversion layer in place, that replaces the Drupal namespace in modules to the Backdrop namespace.

Another cool thing about the Backdrop project is that it lives on Github, which differs from Drupal, that hosts it's own repo. This is fine, but I think in the spirit of being extra open-sourcey, and encouraging developers from all disciplines to collaborate and discover this project, hosting it on github seems like a great idea. So, you can find the project, here: https://github.com/backdrop/backdrop.

If you want to read the project api docs, they can be found here: https://api.backdropcms.org/

Or, if you want to have a look at the project website, that can be found here: https://backdropcms.org/.

And if you wanna get an instance setup quickly without downloading anything, you can fire up an instance on Pantheon, here: https://dashboard.getpantheon.com/products/backdrop/spinup - you'll need to setup a Pantheon acct, but it's free and easy to create.

Happy site building!

Categories: Elsewhere

Mediacurrent: Dynamic Data in Quick Tabs

Planet Drupal - Mon, 02/02/2015 - 22:18

Quick Tabs is a great module, but if your tabs are named Today, Tomorrow, and the name of the day of the week for the next day, it is not obvious how to make the third tab say “Saturday”, “Sunday”, or anything else that changes.

After a quick search for a preprocess function for Quick Tabs didn’t result in a perfectly outlined tutorial, I decided that I would need to dig just a bit.  

Categories: Elsewhere

more onion - devblog: D7: How not to use hook_entity_*

Planet Drupal - Mon, 02/02/2015 - 22:02

Recently I came in a situation where I wanted to extend all entities of a specific type (payment) to reliably have a provide (and store) an additional property. At first glance this seems like a no brainer: simply use hook_entity_* to save/update/load the property to or from the database and that should do it. Turns out it isn't … and there is a lot to learn about how entities work in D7.

Lets take a look at a specific example.

Categories: Elsewhere

Matt Grasmick: Remove language from all Drupal aliases

Planet Drupal - Mon, 02/02/2015 - 21:27

Drupal's locale module includes a lot of great features for supporting multilingual sites. One such feature is the ability to associate a language with a path alias. This allows you to have one node with two versions (let's say an English version and a Spanish version)--each with its own alias.

But your use case may not require language-specific paths per node. Maybe you want to call a spade a spade-- you've got a Spanish node or and English node and that's it. No fancy multiple versions.

Well then you've got a bit of a problem--a few actually. This can wreak havoc with aliases, and pathauto in particular. The solution is the Local Path Ignore module. It ignores the language of a given path, and instead forces all paths to have a language of "undefined," effectively allowing path aliases to behave the way you'd expect--one path per node.

7.x, drupal, locale, i18n, language, pathauto, alias, path
Categories: Elsewhere

Annertech: The 5 best modules to eliminate spam on a Drupal website

Planet Drupal - Mon, 02/02/2015 - 20:31
The 5 best modules to eliminate spam on a Drupal website


Categories: Elsewhere


Subscribe to jfhovinne aggregator