Elsewhere

By default, the Search API Views sub-module does not allow you to specify the "direct parse" mode when configuring an exposed Fulltext filter. Instead, it always uses the "terms" parser which removes special characters and breaks the phrase into terms based on spaces.

This behavior prevents users from really leveraging the simple but robust Lucene query syntax that Apache Solr's default Dismax parser supports:

By default, the Search API Views sub-module does not allow you to specify the "direct parse" mode when configuring an exposed Fulltext filter. Instead, it always uses the "terms" parser which removes special characters and breaks the phrase into terms based on spaces.

This behavior prevents users from really leveraging the simple but robust Lucene query syntax that Apache Solr's default Dismax parser supports:

Drupal sites have a life cycle. Module support shifts from one version of Drupal to the next. New solutions are identified, and old solutions are refined.

For GHSA.net, updating to D7 meant improving mobile support and implementing a cleaner, more regular presentation, and simplifying content management workflows.

This is a discussion of techniques used throughout the project, challenges, and lessons learned.

I was recently in a meeting with a design agency who had to use Drupal for one of their websites and they hadn’t heard good things about it. The points they raised were common ones so I thought I would cover them here. This blog post isn’t a bash against Drupal, we are clearly huge Drupal fans! It aims to cover some of the issues people raise when they say that ‘Drupal is Rubbish’.

Drupal sites are a huge complicated mess!

One of the most common problems that people run into with Drupal is they underestimate its complexity and the knowledge you need to develop a sophisticated site with it. Sometimes people decide they want to use Drupal for all the right reasons, then they go to a web developer and ask them to build the site in Drupal. The web developer looks at Drupal and thinks ‘well, how hard can it be?’ and gets to work. It is a bit like going to your GP and asking them to perform surgery. In this example your GP would say no and refer you to a surgeon, but most developers have an overly optimistic attitude and sometimes it’s just hard to say no to the offer of work. Disaster follows, and often Drupal gets the blame rather than the web developer. Drupal is a fully fledged CMS, built and designed to compete with some of the biggest commercial platforms out there and it requires specialist knowledge to build a well-designed, stable website.

Drupal has to be complex in order to deliver the advanced functionality you need from a high level CMS platform and you’ll hear the phrase ‘steep learning curve’ regularly. This is one of the reasons that as an agency we only work with Drupal as we find that you need to be a specialist to get the best out of Drupal. Even if you are a senior developer with 5 years Drupal experience, you’ll still be learning something new every day. If a developer says they can build sites in WordPress, Joomla! MODX and Drupal, it doesn’t mean they can take on a complicated Drupal build and we would suggest avoiding developers with non-specialist experience for complicated builds.

The admin section is too complicated for our users

To a certain degree, the administration section can appear exceptionally complicated. This is also mainly due to it's extreme flexibility, in Drupal, the admin section will allow the user the ability to do more than a usual CMS administration menu. Luckily, it's very easy to set up different user levels to show less complicated administration screens to some users. Full access to the admin section is suited to users who like to be at super-user level access or to those who have been trained on how to use it. Drupal management and content administration training is something that we can offer and will allow us to take users from basic screens into more complicated task management. 

Before starting a project, doing a quick check to see whether your users are going to need the scalability and flexibility of a large Drupal solution is a good idea, it may be that your solution doesn't need that level of flexibility and a simpler platform like Wordpress may be a better option. 

Drupal is slow

This is possibly the most difficult claim to refute because quite frequently, if you haven’t set up Drupal properly, then yes, it can be slow. It is usually quickly remedied though, and there are a number of posts on the Drupal.org site which can provide you with more information on how to do this. Alternatively you can check out our high availailitity posts by our very own Mark Pavlitski - High performance in Drupal Part 1: Give your site a boost and High performance in Drupal Part 2: Lightning fast code. This comes back to the flexibility of Drupal and corresponding complexity, if your developers are not Drupal specialists, then ensuring that basic speed processes such as caching, memory optimisation and well written SQL could be missed.

We feel that given that some of the world’s biggest sites are written and run in Drupal (www.whitehouse.gov, www.louvre.fr, mtv.co.uk), we’re not too worried about the speed allegations.

Module dead ends

One of the reasons for Drupal’s success are the 24,000 or so developers that contribute code to the community, who produce a wide range of modules that every Drupal user can benefit from. Whenever something new appears, i.e. Twitter, Pinterest, an enterprising Drupal developer will bring out a module for it. Usually this happens well before the commercial CMS companies with their limited development teams and fixed development roadmaps can respond.

Sometimes, that enterprising developer who spent time writing a module, decides that continuing to support the module or upgrading it to work with the latest Drupal release is not something he or she wants to do any more. Hence module dead ends.

There are a few options for you out there if this happens: replacing it with a different module can often be quick and easy, taking over the maintenance of the module can be easily done and you can then assume control of that module. Evaluating whether a module is going to be developed long term can be an art form for Drupal developers so keep an eye out for an article coming soon on this site about the Top 5 factors to look for when choosing a module.

Summary

Drupal is a very flexible system and can be limitless in its opportunities and potential but this has to come with a level of complexity, a level that can make it unsuitable for developers without the required experience. The possibilities for doing exciting things like module customisations to fine tune Drupal to work perfectly for your site are endless, we just suggest that you employ developers with the best experience possible for your needs.

The title alone says it all. If you're reading this post, it probably is because you desire an easier way to insert a simple icon into your Drupal site. Many times this involves adding an icon library into your theme and doing some pretty undesirable pre-processing or template overrides to insert them where you want.

What are icons?

They're images right? Well, technically yes. Icons are a visual representation of some intended object or action -  a pictogram essentially (think of a stop sign). What I'm really asking though is:... Read more

Per ">Dries's post about Drupal 8 release risk, this post outlines a plan jointly developed by the Drupal core maintainers (Dries, webchick, catch, and alexpott) for getting Twig into core safely. See that post for more background information.

What's up with Twig?

The Twig template engine was originally committed to Drupal 8 live on stage at BADCamp in November 2012, to wild fanfare. Since then, the team has been working on converting all templates and theme functions in Drupal core to use Twig. Thanks to valiant effort by numerous contributors, the PHPTemplate conversions currently stand at ~30% RTBC, and another ~45% at needs review. This is great progress!

Why aren’t the core committers committing?

The short answer is release risk. We are in the “clean up” phase of the Drupal 8 release cycle (http://drupal.org/core/release-cycle#clean-up-phase). Each commit we make should take us one step closer to a Drupal release. In effect, committing an individual Twig patch to core takes us one step further into uncharted territory. At the moment all of our templates are PHPTemplate and hence each conversion commit moves us further away from a release. We obviously can't ship with two theme systems, so unless 100% of templates are converted, we leave Drupal 8 in an unreleasable state.

Solution

We plan to merge all the PHPTemplate to Twig conversions into one patch. Once complete, we will commit this patch into the mainline 8.x branch. The patch will convert all the .tpl.php files to .twig and remove the functionality that allows Drupal 8 to run both theme engines at the same time. This means that Twig commits will not take the 8.x branch further away from a release, and it gives us an exit strategy if they are not complete by code freeze.

A meta issue has been created to track the merged patch.

The Twig team will:

• Finish converting all the templates.
• Provide benchmarking evidence on each issue that the conversion conforms to the acceptance criteria. If other patches are required to be applied in order to meet this requirements then these should added to both the conversion issue and the meta issue.

Core committers will:

• Review each individual patch and
  • Comment: "+1. Ready for [#1987510]"
  • Status: "closed (duplicate)"
  • Title: prepend '[READY] '
• Commit the merged patch once all templates have been converted and acceptance criteria have been met.
• If a Twig patch is isolated to the current Twig code in 8.x then the core committers will commit it immediately. For example: Allow and test for NULL and integer 0 values in Twig templates

Acceptance criteria

The following are necessary in order to perform the final merge of conversions into 8.x:

• 100% Twig conversions are completed
• 8.x-twig performance is comparable with 8.x PHPTemplate performance, bearing in mind the issues with D8 performance testing - see https://drupal.org/node/1888424#comment-7345926
• there are no critical Twig follow ups

Once the patch is committed further Twig work should continue on 8.x to:

• Convert theme functions to Twig
• Gain the security benefits on Twig
• Further performance enhancements made possible by moving to Twig

Important: It is in everyone’s interest that the conversions are finished as soon as possible. In an ideal world, the merge will take place during Drupalcon Portland.

Rollback criteria

If by 17th June the acceptance criteria are not met, then (with regret) an issue will be created to remove Twig from Drupal 8.x. This gives enough to time to create and test the rollback patch before code freeze on 1st July.

Help wanted!

The Twig team has been doing a tremendous job, and we know the front-end community is very excited about this initiative. The time is definitely here to jump in and help the team push this initiaitve past the finish line! Particularly needed are patch reviews (see http://www.youtube.com/watch?v=Bv4PY_ZEP4Q for a helpful screencast on how to do so!), since most issues have patches but can't be RTBCed by people who worked on them.

So grab an issue to review and/or drop by #drupal-twig on IRC if you'd like to help. It's a great way to learn about Drupal 8, meet awesome people, and vastly improve Drupal for front-end developers at once!

We are please to report that we held "100th, Tokyo Area Debian Meeting"... yes, 100th!!! (since 2005), 11th May in Shibuya, Tokyo


Discussed about "stable" releasing,


lectured "cdn.debian.net" by Yasuhiro Arakiand "modern packaging" by Osamu Aoki.


Also, Ubuntu folks showed "Ubuntu phone" and it looks good and interesting (however, it's on the development stage, yet).Then, party!!! :-) happy to release "Wheezy"






I hope we'll hold "Jessie" in early 2015.

If you updated recently your system to Debian wheezy and you are using vsftpd with enabled chrooted local users ...

[~] # grep -i ^chroot_local_user=yes /etc/vsftpd.conf | tail -1 chroot_local_user=YES

... you maybe faced with the following problem:

500 OOPS: vsftpd: refusing to run with writable root inside chroot() Login failed.

This problem raised already in Bug #656900 and it was fixed by adjusting the documentation. Beside that there maybe configurations you want to relax such a strict check. Unfortunately this feature was implemented in version 3.0.0 which is not part of Debian wheezy:

- Add new config setting "allow_writeable_chroot" to help people in a bit of a spot with the v2.3.5 defensive change. Only applies to non-anonymous.

The Frontier Group created a patched package of vsftpd for Ubuntu. After reviewing the patch we decided to also create a Debian package for wheezy.

You can easily install the package by the following sniplet:

echo "deb http://ftp.cyconet.org/debian wheezy-updates main non-free contrib" >> \ /etc/apt/sources.list.d/wheezy-updates.cyconet.list; \ aptitude update; aptitude install -t wheezy-updates debian-cyconet-archive-keyring vsftpd && \ echo "allow_writeable_chroot=YES" >> /etc/vsftpd.conf && /etc/init.d/vsftpd restart

Updates, in case of bugfixes in Debian wheezy, should be also available through this distribution channel.

This was fascinating. They've basically done some very simple things in (what they perceive to be) the idiomatic way in a bunch of different web frameworks and platforms, and compared performance. Unfortunately, the one I consider the most realistic (the “fortunes” test, since it actually spits out HTML in the end) is not run for that many frameworks yet, but it's a very good measure.

The very coarse summary is that Java and Go do well, Node.js and (raw) PHP do quite okay, and Django and Rails do crap. This is pretty much in line with what I'd expect, but most Django and Rails developers I do mostly go “LA LA LA” with regards to performance… (And this is with simple things; you know, those that come before you need a complex query your ORM really can't handle.)

Also note: The difference between raw PHP and the fastest PHP framework in the test is about 3x.

In this tutorial I am going to show you a way you can leverage the power of the Drupal Form API to display form fields in the layout you want. To illustrate this, I will alter a form (the comment form) and arrange the Name and Subject fields in two columns.

I recently started a new development position with Blink Reaction so I needed to get somewhat serious about setting up a local Drupal development environment.

Ariadne

I was leaning towards making use of Vagrant for managing local development environments so I can easily switch between different projects or branches. I also believe Vagrant makes it easier to have as close a mirror to production locally as possible.

I discovered a very interesting project from MyPlanet Digital named vagrant-ariadne. Ariadne is a customized implementation of Vagrant and allows for easy deployment of Drupal installation profiles to a local VM. Another nice feature is that it attempts to emulate Acquia’s infrastructure. This is useful as a lot of Blink’s clients are deployed on the Acquia Cloud.

Assuming you have Vagrant, rvm and a ruby environment installed on your workstation, installing Ariadne is pretty straightforward:

j vagrant gem install vagrant-vbguest vagrant-hostmaster vagrant-librarian [sudo] gem install librarian rake knife-solo git clone https://github.com/myplanetdigital/vagrant-ariadne.git cd vagrant-ariadne bundle install bundle exec rake setup

Everything is now configured to boot a virtual box. Ariadne comes with a simple example that can be deployed:

j project=example vagrant up

Once that command finishes running, the site can be viewed at http://example.dev/ (Ariadne uses vagrant-hostmaster for managing /etc/hosts entries).

A more involved cookbook is a cookbook for deploying the Web Experience Toolkit available on github also. If we wanted to deploy the master branch of this site, we could do:

bundle exec rake "init_project[https://github.com/wet-boew/ariadne-wet-boew-drupal]" project=wet-boew-drupal branch=master vagrant up

And that’s it!

Another nice feature of these deployed environments is that they are configured to allow remote debugging (relevant when setting up an IDE as mentioned later) and the actual site code is shared as an NFS mount. For example, the contents of my /etc/exports file after booting a box with Ariadne looks like:

# VAGRANT-BEGIN: 7ac1cf50-4498-4e49-bd66-edac4a9b2d7e "/Users/posullivan/vagrant-ariadne/tmp/apt/cache" 33.33.33.10 -mapall=501:20 "/Users/posullivan/vagrant-ariadne/tmp/drush/cache" 33.33.33.10 -mapall=501:20 "/Users/posullivan/vagrant-ariadne/data/html" 33.33.33.10 -mapall=501:20 # VAGRANT-END: 7ac1cf50-4498-4e49-bd66-edac4a9b2d7e

Thus, if I navigate to the ~/vagrant-ariadne/data/html directory or import that in my IDE, I can edit the code deployed on the vagrant box.

Drupal Core from git

Another use I’ve found for ariadne is building a local environment for the latest drupal core. To accomplish this, I created a role file named roles/core.rb with the following contents:

name "core" description "Install requirements to run Drupal core." run_list([ "recipe[mysql::server]", "recipe[mysql::client]", "recipe[php::module_mysql]", "recipe[php::module_curl]", "recipe[php::module_gd]", "recipe[php::module_apc]", "recipe[drush::utils]", "recipe[drush::make]", "recipe[php::write_inis]", ]) default_attributes({ :drush => { :version => "5.8.0", }, :mysql => { :server_debian_password => "root", :server_root_password => "root", :server_repl_password => "root", :bind_address => "127.0.0.1", :tunable => { :key_buffer => "384M", :table_cache => "4096", }, }, })

j

Next, I created a new cookbook project named core and created a simple default.rb recipe for this cookbook. This recipe looks like:

branch = node['ariadne']['branch'] git "/mnt/www/html/drupal" do user "vagrant" repository "http://git.drupal.org/project/drupal.git" reference branch enable_submodules true action :sync notifies :run, "bash[Installing Drupal...]", :immediately end bash "Installing Drupal..." do user "vagrant" group "vagrant" code <<-EOH drush -y si \ --root=/mnt/www/html/drupal \ --db-url=mysqli://root:root@localhost/drupal \ --site-name="Drupal Core Installed from Git" \ --site-mail=vagrant+site@localhost \ --account-mail=vagrant+admin@locahost \ --account-name=admin \ --account-pass=admin EOH end site = node['ariadne']['host_name'].nil? ? "#{node['ariadne']['project']}.dev" : node['ariadne']['host_name'] web_app site do cookbook "ariadne" template "drupal-site.conf.erb" port node['apache']['listen_ports'].to_a[0] server_name site server_aliases [ "www.#{site}" ] docroot "/mnt/www/html/drupal" notifies :reload, "service[apache2]" end

With all of the above in place, its quite simple to create a local VM based on the latest in the 7.x branch of drupal core:

project=core branch=7.x vagrant up

The above command simply needs to have the branch name modified to deploy a different branch. Once the above command completes, a site will be available at core.dev and I can log in as the admin user using the credentials specified in my cookbook.

Private Repositories

Most repositories for client projects are stored in private repositories. Thankfully, thats not an issue with ariadne. Ariadne uses agent forwarding to forward the host machine’s ssh session into the VM, including keys and passphrases stored by ssh-agent. What this means is that your VM will have the same Git/SSH access that you enjoy on your local machine. I’ve not had a problem checking out code stored in private repositories on bitbucket for example.

IDE

For an IDE, I’ve been an Eclipse user in the past for Java projects I’ve worked on so Aptana seemed like a good fit for my needs at the moment. A few existing articles already exist on configuring Aptana for Drupal development so I’m not going to go into too much details here.

Installation is very straightforward with the binary downloaded from the site. A ruble exists for Drupal so its pretty natural to install that:

git clone git://github.com/arcaneadam/Drupal-Bundle-for-Aptana.git ~/Documents/Aptana Rubles/Drupal-Bundle-for-Aptana

Next item is to configure Aptana to adhere to the Drupal coding standards. I used an existing profile for Aptana that could be imported for this.

The final thing I needed to configure was a debug configuration. To do this, I created a new PHP web page configuration. First, a new PHP server needs to be added. In this example, lets assume I am using the example box I mentioned in the Ariadne section whose hostname is example.dev. The web server configuration dialog when configured with this hostname and appropriate directory for the site root looks like:

Once a PHP server has been added, the rest of the information to fill in for the debug configuration is pretty straightforward as shown below:

I like to select the break at first line option to make sure the debug configuration works correctly.

With this in place, any visit to example.dev will result in the breakpoint being hit.

Conclusion

I’ve still not settled on this combination for my development environment but I was definitely pretty excited upon discovering the Ariadne project. The drawbacks that I see to using Ariadne are: 1) the need to create a cookbook for each project you want to work with, 2) the project is still in beta stage so documentation is fairly lacking (fair enough for a beta project though), and 3) if you are not familiar with chef, using Ariadne may prove challenging (although it provides the perfect excuse to become familiar with chef).

PHPStorm is the IDE that seems to be pretty popular when I ask what other people are using for an editor but given there is a license fee associated with it, I didn’t want to splurge on that just yet. Aptana looks to work just fine for me and satisfies my needs nicely.

I recently ported my old module Password Require, which allows password protecting any form in Drupal, to Drupal 7.  This module was originally created for my presentation at the Florida Drupal Camp in 2010, as an introduction to module development.

 

A couple of days ago, I had an opportunity to give a guest lecture on our Rcpp package for R and C++ integration. This was in CMSC 12300 Computer Science with Applications-3 in the Department of Computer Science at University of Chicago. The course is the final part of a three term sequence introducing students to data-centric work in R, Python, Java and C++. I tried to keep it brief and engaging in order to motivate the why or R/C++ integration while providing plenry of useful examples.

And yesterday I got to spend a day giving an invited day-long workshop at the Medical College of Wisconsin as part of a two-day R workshop sponsored by the Milwaukee Chapter of the American Statistical Assocation as well as the CTSI and PCOR centers at the Medical College of Wisconsin. In the workshop, I followed the previously-used setup of four parts on introduction, Rcpp details, advanced topics and last-but-not-least applications, but also updated and extended to more recent topics.

Pdf slides from both events are now on my presentations page.

after the release is before the release. this week I started to pick up my RC bug squshing activities again. first results:

• #675231 – psad: "psad: prompting due to modified conffiles which were not modified by the user"
  add a comment to the bug report
• #700527 – libjs-jquery: ""libjs-jquery broken by movabletype-opensource << 5.1.4+dfsg-3~""
  upload to DELAYED/2 with patch (adding Conflicts) prepared by a fellow DD, then uploaded by maintainer
• #706764 – assaultcube-data: "assaultcube-data: fails to upgrade from squeeze - trying to overwrite /usr/share/man/man6/assaultcube-server.6.gz"
  add Breaks/Replaces as suggested in the bug report, upload to DELAYED/2
• #707686 – dhelp: "dhelp: FTBFS and uninstallable in sid: needs ruby-gettext"
  file new bug with patch

besides that I've also started to look at the "FTBFS with perl 5.18 in experimental" bugs which are not RC yet. – yes, perl 5.18 is already in experimental!

Our second event adopted an alternative format not by design but its usefulness has us thinking it may well be the way to go!
Speaker at the seond DPSX event:
Mark Smitham  – Cabinet Office (G-Cloud) A huge thank you… Mark, we appreciate‏ the knowledge shared; old hats, newbies and the curious, we all took away a lot from the discussions.
And the key points shared and discussed:
+ G-Cloud is about engaging the SME sector – it is access to the eco-system #GCloudJoinin
+ has delivered the equivalent of £180m+ in savings; introducing innovative SME enterprises into the eco-system
+ G-Cloud is about greater transparency: there are 29,000 Govt. customers on G-Cloud – the access to opportunities for the SME sector is unparalleled  
+ The new G-Cloud Store interface by the way is a sight of relief! job well done. Note: G-cloud is a non transactional store but a marketplace for Govt. customers to have access to selected SME suppliers that they can engage with
+ on the CloudStore good old SEO is handy for searchability and visibility
+ There are challenges to getting the critical mass from the Govt. customers… SMEs could assist and inform their clients and prospects of the G-Cloud route to product/service acquisition.
+ a short guide to understanding Impact levels and Pan-Govt accreditation

some useful links:
G-Cloud
CloudStore
if you are a buyer
if you are a supplier

if you are not on the G-Cloud as a supplier  and as a Customer/buyer
LocalGov Digital ‏

The next meet-up for Drupal Public Sector Exchange will be held next month and stay tuned on our Twitter account DPSX ‏@DPSXchange

DPSX: @Alanpeart @Calert @Greenman @Kubair @MarcDe_ath @shaunwilde
#Drupal #PublicSector #Innovation #G_Cloud_UK #LocalGovDigital

A week ago, I made the big step and presented my resignation letter at Google. It was not an easy decision, to leave a good job to pursue a blurry plan that sounds a bit infeasible, but I feel this what I want to do: it's a dream becoming reality.

After the 31st of May, I will become self-employed, working as a freelancer, while travelling around the world. I plan to live with a small budget, working with my laptop from wherever I am, instead of stressing about getting many clients to keep an expensive lifestyle.

I've had the travelling bug for some time, always thinking about my next trip, leaving for the airport just after finishing work, coming back on Monday and going directly to the office. You end up wishing for more vacation days all the time (and I had a fair amount of them). Now, for different reasons I want to spend some time in my old house in Nice, and in Argentina. There was no way I could do that with my current job, and that was the trigger for my decision.

After that, I will come back to Ireland, just to think where my next destination will be. I know this is going to be a great experience, we'll see how well it works!

If you think you -or your employer- might need my services, I'd be more than happy to talk! I'll be concentrating on the kind of work I've been doing at Google and before: finding creative solutions for difficult problems, be it systems administration, or (systems) programming. Think of hiring an SRE for just a few hours or days.

I've just released qcontrol 0.5.1. Changes since the last release:

• Add build targets to enable static linking (Original patch by Frans Pop).
• Wake-on-Lan and EUP control (by Michael Stapelberg, Debian bug #703888).
• Updated example configurations (based on Debian package).
• Support loading configuration snippets from a directory (Ian Campbell, Debian bug #697574).
• Various other bug fixes.

I also put together a very basic homepage.

Get it from gitorious or http://www.hellion.org.uk/qcontrol/releases/0.5.0/.

The Debian package will be upload shortly.

I was asked by some people to write a status report about the whole PK/AS/LI stuff – sorry guys that it took so much time to write it .

PackageKit

(PackageKit is an abstraction layer for package-management systems, allowing applications to access the package-manager using simple DBus calls)

PackageKit is an incredibly successful project. With the 0.8.x series, it received many performance improvements, and has now the same speed on my computer than the distribution’s native tools. PackageKit is used in almost all major Linux distributions, except for Ubuntu. But even Ubuntu has written some compatibility layer, so most calls to PackageKit will work.

(I am not sure what Arch and it’s derivatives do, but I assume PK might be used there too)

Debian Wheezy includes PackageKit by default, and in Jessy we are going to replace some distribution-specific tools with PackageKit frontends (mostly the old and unmaintained update-notifier and Software-Updater – no worries, we are not going for a Synaptic replacement (currently this won’t be possible with PK anyway))

Unfortunately, some PackageKit backends are still not adjusted for the 0.8.x API and are only running on 0.7.x. This is bad, since 0.8.x is a huge step forward for PackageKit. But the situation is slowly improving, with the latest OpenSUSE release, the Zypper backend is now available on 0.8.x too.

Being able to run a PackageKit from the 0.8.x series is a requirement for both AppStream and Listaller.

AppStream

(AppStream is a cross-distro effort for building Software-Center-like applications. It contains stuff like a screenshot-service, ratings&reviews etc. The most important component is a Xapian database, storing information about all available applications in the distribution’s repositories. The Xapian DB is distro-agnostik, but distributors need to provide data to fill it. AppStream offers an application-centric way to look at a package database)

The AppStream side doesn’t look incredibly great, but the situation is improving. As far as I know, OpenSUSE is shipping AppStream XML to generate the database. Ubuntu ships the desktop-files, and I am working on AppStream support in Debian’s Archive Kit. On the Fedora side, negotiations with the infrastructure-team are still going on. I haven’t heard anything from Mageia and other AppStream participants yet.

On the software side, Apper (KDE PackageKit frontend) has full support for AppStream. Apper just needs to be compiled with some extra flags to make it use the AppStream database.

On the GNOME-side, GNOME-Software is being developed. The tool will make use of the AppStream database, on distributions where it is available.

Using the Ubuntu Software Center on not-Ubuntu-based distributions ist still not much fun, but with the AppStream database available and a working PackageKit 0.8.x with a backend which supports parallel transactions, it is possible to use it.

On the infrastructure side: I recently landed some patches in AppStream-Core, which will improve the search function a lot. AppStream-Core contains all tools necessary to generate the AppStream database. It also contains libappstream, a GObject-based library which can be used to access the AppStream database.

Also, we discuss dropping PackageKit’s internal desktop-file-cache in favour of using the AppStream database. If we do that, we will also add software descriptions to the AppStream db, to improve search results and to speed up search for applications. Because we have to deprecate API for that, I expect this change to happen with PackageKit 0.9.x.

As soon as the Freedesktop-Wiki is alive again and my account is re-enabled, I will create compatibility-list, showing which distribution implements what of the PK/AS/LI stuff, especially focusing on components needed for AppStream.

Only a few distributions package AppStream-Core so far. Although it is beta-software, creating packages for it and shipping the required data to generate the AppStream database would be a very huge step forward.

Listaller

(Listaller is a cross-distro 3rd-party software installer, which integrates into PackageKit and AppStream. It allows installing 3rd-party applications, which are not part of the distributor’s repositories, using standard tools used also for native-package handling. Everything which uses PackageKit can make use of Listaller packages too. Listaller also allows sandboxing of new applications, and uses an AppDir-like approach for installing software.)

Listaller is currently undergoing it’s last transition before a release with stable API and specifications can be made. Dependency solving will be improved a lot during the current release-cycle, making it less powerful, but working on all distributions instead. (Fedora always had an advantage in dependency-solving, due to RPM providing more package metadata for Listaller to use) This change was delayed due to discussing a possible use of ZeroInstall-feeds to provide missing dependencies with the ZeroInstall team. We did not come to a conclusion about extending the XML, so Listaller will contain an own format to define a dependency, which can reference a ZeroInstall feed. That should be a good solution for everyone.

All these changes will result in IPK1.2, a new version of the IPK spec with small changes in the pkoptions file syntax and huge changes in dependency-handling. The new code is slowly stabilizing in a separate branch, and will soon be merged into master.

The next Listaller release will be the last one of the 0.5.x series, we will start 0.6.x then. KDE currently has support for Listaller through Apper, which is enabled on a few distributions. In GNOME, optional Listaller support is being developed and will be available in one of the upcoming releases.

Currently, to my knowledge, only a few distributions package Listaller. This should improve, so it is easier for application developers to deploy IPK packages.

The upcoming changes in KDE and GNOME to build stable developer platforms will help Listaller a lot in finding matching dependencies, and for stuff which only depends on one software frameworks, installations should be a matter of seconds.

As you can see, lots of things are happening, and there is improvement in all components related to installing and presenting software on Linux machines. However, all these projects have a severe lack of manpower, especially AppStream and Listaller have the lowest number of developers working on the tools (at time, only two active developers). This is the main reason for the slow development. But I am confident that we will have something shipped in the next distribution releases. At least AppStream should be ready then.

Quick tip: Use bash aliases to easily run multiple versions of drush at onceSunday, 12th May 2013

There are times where it can be desirable to run two or more different versions of drush on one computer, or even multiple versions for one user.

For example, if you're using a server running the 1.x (stable) branch of Aegir and you attempt to upgrade from drush 4 to 5 globally all of your provision tasks will start failing, rendering Aegir completely useless.

The "real" solution is to upgrade Aegir to the 2.x branch but if you're looking for a quick fix it's easier to just install drush 5 in parallel with drush 4 for your user.

Steps to install drush 5 in parallel with drush 4:

This assumes you already have drush 4 installed, so that running $ drush status will report version 4.x

1. Download the latest version of drush 5 from the project page.
2. Extract the contents of the drush tarball into your home directory in a folder called drush5, so that the drush files can be found at ~/drush5.
3. Edit or create either ~/.bashrc or ~/.bash_profile and add the following line: alias drush5='~/drush5/drush'.
4. Reload your terminal/console or run $ source ~/.bashrc or $ source ~/.bash_profile as appropriate (whichever file you edited).

That's it! if you run $ drush5 status you should see a drush report a version number 5.x

You can now swap between drush 4 and 5 easily whenever you need to.

These steps can be adapted to do the same thing in reverse and have drush 5 run with the drush command and drush 4 with drush4, or you could even have each version explicitly mapped to drush4 and drush5 - it's up to you :)

Syndicate: planet drupal

Knowledge Language English My Mentor/D8MI Drupalcon Portland ScheduleCathy Theys05/12/2013 - 08:28

This is a wishful schedule. Some things I'm committed to be at. Some I'm wishing I will to have time to go to.

Note, the google core mentoring calendar will make it easy to add some of these to your calendar. Core mentoring calendar: 7ss54o2foktlc8b75d1gest4do@group.calendar.google.com

It's a mix of what I'm into: my sessions, mentoring and multilingual.

Tuesday

• 9:00am Programming Diversity by Ashe Dryden
• 10:15am Making core development sustainable by Greg Dunlap
• 11:30am The Current State of Drupal 8 Keynote by Dries (is what I would go to if I were not staffing the Community booth at that time.)
• 2:30pm I'm going to be trying to be calm right before my session. But if not, I'd pick: Dependency Injection in Drupal 8 by Katherine Bailey
• 3:15pm I'll be at my session! Running coaches wanted! Contribution sprints and trainings by Jess, Andrea, Addi and me
• 4:30pm I'll be in a BoF with mentors doing task selection for the Friday sprint, but if I were not, I'd be in UX Case: Love and Hate in The Issue Queue Garden by Michael Keara, Thomas Svenson
• 5:30pm Exhibit Hall for Drupalcon Kick Off Reception
• 6:00pm or so Women in Drupal Meet and Greet

Then on Weds...