FLOSS Project Planets

Drupal Watchdog: Catche That Typo!

Planet Drupal - Fri, 2015-10-23 13:27

The core Drupal community is notorious for obsessing over every little detail that is submitted as code. Single issues can have hundreds of comments and, at its very worst, can take years to be resolved.

As a community, though, we know that this obsession results in a much better product. Code quality comes at a cost: time. It is nearly impossible to both comprehensively review code and commit code quickly. But the upfront time costs for peer review will save you time down the line. Teams I've worked with have caught typos, security vulnerabilities, broken styles… you name it, we've caught it before it was deployed, thanks to the peer review process.

The remainder of this article outlines the step-by-step process needed to conduct a peer code review.

Working on New Code

Each time you start new work, make sure your local environment is as pristine as possible. Ideally, this would also include downloading a fresh copy of the database from your production server to ensure there are no half-baked Feature settings which could dirty your export.[1]

With the build environment as clean as possible, you're ready to start.

Categories: FLOSS Project Planets

Six Mile Tech: BadCamp for Drupal Newbies

Planet Drupal - Fri, 2015-10-23 13:14
Are you at BadCamp and new to Drupal? There will be tons of great sessions this weekend but I told my Beginning Drupal 8 class that I would send them a list of Drupal Beginner oriented sessions. If you are new to Drupal or just want a refresher on some basic Drupal concepts you might find these sessions useful.
Categories: FLOSS Project Planets

Announcement: Marble ships the oldest existent historic Globe

Planet KDE - Fri, 2015-10-23 12:27
KDE Project:

Today I have the pleasure to announce that Marble is the first popular virtual globe that ships and visualizes the Behaim Globe. The Behaim Globe is the oldest surviving terrestrial globe on earth. It was created between 1492 and 1493 - yes at the same time when Christopher Columbus made his first voyage towards the west and "discovered" America. This fact makes the Behaim Globe very special and also subject to scientific research: It documents European cartography during that era and it's probably the only historic globe which completely lacks the American continent.

These days the Behaim globe can be visited in the Germanisches Nationalmuseum in Nuremberg, Germany. The Germanisches Nationalmuseum (GNM) has kindly granted the Marble project permission to release the photo scan material of the Behaim Globe under the CC BY-SA 3.0 license and they have supported us in bringing it for the first time to the users of a widely deployed virtual globe: Marble. Right now our users can immediately download the Behaim Globe from inside Marble by entering File->Download Maps (or download it via our maps download website.).

Starting with the next Marble release scheduled for December 2015 the Behaim Globe map theme will become a regular part of the map themes that are shipped with the Marble installation package by default.

In addition the Marble project released a special Behaim Marble version in the Google Play Store. So users of Android devices – like smartphones and tablets – can enjoy the Behaim Globe, too! This also marks the first public release of a Marble based application on Android devices.
The Behaim map theme for Marble was created as part of the master thesis (Diplomarbeit) 3D Modelling of the Behaim Globe using Marble by Halimatou Poussami. The map theme allows to pan and zoom the whole Behaim Globe - curiously the whole globe is almost fully covered with detailed inscriptions in early modern German. Via checkboxes in the legend tab inside Marble our users can also overlay today's accurate coastlines. This allows to compare the Behaim cartography with today's known actual coastlines. Quite obviously the Behaim map depicts the continents stretched in longitude. So the creators of the Behaim Globe have probably based their globe on an earth radius value that was too small.

The photographic material of the Behaim Globe is based on digital scans made by the Friedrich Alexander University (FAU) in Erlangen-Nuremberg and the IPF TU Wien. These scans were performed using polarized light. This is also part of the reason for the vibrant colors that you can see in the map theme - visually the colors of the Behaim globe are much more subdued. During the past centuries the Behaim Globe has been subject to several "restoration attempts" and "editing", which also resulted e.g. in text changes. Therefore today's scientific research also focuses on the Behaim globe as a palimpsest. Using Marble's legend tab our users can compare the photomaterial of the Behaim Globe with facsimile drawings from 1853 and 1908 which also reveals differences.

The Marble Team would like to thank the Germanisches Nationalmuseum for its decision to release the Behaim imagery under the CC BY-SA 3.0 license. In particular we'd like to thank Dr. Thomas Eser (GNM), Prof. Dr. Günther Görz (FAU) and Halimatou Poussami for their active support in bringing the Behaim Globe to our Marble users and to the public!

Categories: FLOSS Project Planets

Krita on OSX

Planet KDE - Fri, 2015-10-23 11:23

Ever since our first kickstarter in 2014, we've been building every release of Krita for OSX. The initial work to make that possible took two weeks of full-time hacking. We did the work because Krita on OSX was a stretch goal and we wanted to show that it was possible to bring Krita to OSX, not because we thought two weeks would be enough to create a polished port. After all, the port to Windows took the best part of a year. We didn't make the stretch goal, and the port to OSX got stuck.

And that shows. We build Krita on a mid-2011 Mac Mini that runs Mavericks. That has a couple of consequences: Krita doesn't run well on anything but Mavericks, and the hack-build-test cycle takes about half an hour. That means that fixing bugs is nigh on impossible. Some things have been broken since the start, like OpenGL, other things broke along the way, like proper tablet support, loading and saving jpeg files. And more.

Still, though we didn't make the stretch goal, the demand for Krita on OSX is there: we're getting about half a dozen queries a week about Krita on OSX. So, what should be the next steps?

Step one: define the goals. That's easy. Krita on OSX should run on all versions of OSX that are supported by Qt5, be a good citizen, that is, come as an app bundle in a disk image, save settings to the usual locations, use the regular temporary file location and provide the same feature set and performance as on Windows and Linux. (Which might be difficult because of problems with Apple's OpenGL implementation: Apple wants developers to use their platform-specific alternative.)

Step two: estimate the effort needed. With the Qt5/Kf5 port of Krita, estimation is more difficult because only now people are creating the first Kf5-based applications on OSX, and are running into new and interesting problems. Things like finding resources in standard locations: for Krita 2.x, we had to hack KDE's standard paths implementation quite severely. The main issues are: OpenGL, tablet support, standard paths, bundle creation, platform integration and optimization.

My best effort estimation is three to four months of nearly full-time work. That's similar to the Qt5 port, and comes to about 12,000 to 16,000 euros. Add in a decently fast Mac, and we're looking at, roughly, an investment for 15,000 to 19,000 euros. Add a bit for unexpected events, and let's say, 20,000 euros. A lot of money, but actually quite cheap for a development effort of this kind. It's more than the Krita Foundation has availabe, though...

There is a secondary consideration, borne from experience with the Kf5/Qt5 port: if it will take three months of development time, then that development time is not spent on other things, like bug fixes or kickstarter features. That will have an immediate impact on the project! The port has already made the bug list grow horribly long, because work on the port meant less work on bug fixes.

If we decide to it, step three then must be: do it... There are a couple of possibilities.

The first: run a kickstarter campaign to get the money. Wolthera and I actually started setting one up. But we're just not sure whether a kickstarter campaign is going to succeed, and to fail would be really bad. It would reflect badly on Krita as a wider project and might jeopardize the 2016 kickstarter campaign to fund the next round of feature improvements. It might even cannibalize the 2016 campaign. We're not sure how likely that is, though, because we're not sure the campaigns would be targetting the same user group. Right now, our campaigns are supported in equal parts by free software enthousiasts and by artists. We're not reaching the OSX community, because Krita isn't ready on OSX, but conversely, we don't know how to reach the OSX community. We don't even know whether the OSX community can be involved enough to reach a funding level of at least 15,000 euros.

That makes starting a kickstarter campaign (which is in itself two months of full-time work) a really dicy proposition. Even cutting the goal up into tranches of 5000 euros for the basic port (and a new Mac) and then stretch goals of 2500 euros seemed chancy to us. Plus, if we get stuck at 5000 euros there really is not enough money to do a decent port.

The second possibility: fund it out of pocket, and try to get the investment back. That could be done by making Krita for OSX exclusively available on Steam, or by a possible increase in donations because we can now reach the OSX user community. The first option could be scotched by someone taking our work and making Krita available gratis on OSX. That would be totally OK of course: Krita is free and open source. Nothing says we have to give our binaries aways, but on the other hand, nothing can stop anyone else from giving our binaries away. Or making their own, once the hard work is done. The second possibility, increased donations, is a kind of gamble. It might work out, or it might not...

The third possibility: fund the development out of pocket, but take a longer period to work on it. Get a Mac and devote, say, two weeks of initial work, and then invest a day a week to OSX. Slice up the week. A bit like I'm now doing four days a week of paid non-krita development to fill up my empty bank account, one day a week of porting and one day a week of stable-version bug fixing.

The final possibility is to do nothing. Maybe a capable OSX-loving developer will come around and start doing the work out of love for Krita. But I'm not sanguine about that happening, since we've seen four or five people trying to build Krita on OSX, and all but two failed. The first attempt was using MacPorts, which doesn't lead to an installable app bundle, and the second attempt was the one done for the 2014 Kickstarter.

Which brings us full-circle to the question: what now?

Categories: FLOSS Project Planets

Frederic Marand: Drupal 8 tip of the day: replace hook_drush_command() by a YAML file

Planet Drupal - Fri, 2015-10-23 10:35

One of the big trends during the Drupal 8 creation has been the replacement of info hooks by two main mechanisms: annotations, and YAML files. In that light, hook_drush_command(), as the CLI equivalent of the late hook_menu, replaced by various YAML files, looks just like a perfect candidate for replacement by a commands section in some mymodule.drush.yml configuration file. Turns out it is incredibly easy to achieve. Let's see how to kill some hundred lines of code real fast !

read more

Categories: FLOSS Project Planets

Visualize dependencies of binaries and libraries on Linux

Planet KDE - Fri, 2015-10-23 10:33
Update4: Albert Astals Cid mentioned that KDE maintains also a version of that script: draw_lib_dependencies

Update3: Marco Nelissen fixed an issue, that caused dependency resolution to break, as soon MAXDEPTH was reached once. This issue was fixed now and I am quite happy that this old script is still useful and even get's improved. The updated version can also be found at dependencies.sh. Version below fixed as well.
Update2: pfee made some more fixes. The script parses now the dependcies tree correctly using readelf and ldd so that only direct dependencies apear in the graph. The updated version can also be found at dependencies.sh

Update: Thanks to the feedback from pfee, I made some fixes to the script. The script is now also available for direct download dependencies.sh

Sometimes it is useful to know the library dependencies of an application or a library on Linux (or Unix). Especially OpenSource applications depend on lot's of libraries which in turn depend on other libraries again. So it is not always quite clear which dependencies your software has.

Imagine you want to package up your software for a customer and need to know on which libraries your software depends. Usually you know which libraries were used during development, but what are the dependencies of these libraries? You have to package all dependencies so that the customer can use and/or install your software.

I created a bash-script which uses ldd to find the dependencies of a binary on Linux and Graphviz to create a dependency graph out of this information. Benedikt Hauptmann had the idea to show dependencies as a graph - so I cannot take credits for that. Using this script I created the depency graph of TFORMer, the report generator we are developing at TEC-IT. The result is a nice graph showing all the dependencies a user has to have installed before using TFORMer.

Another beautiful graph is the one of PoDoFo. See below the graph of PoDoFo.

The dependencies of Firefox are way more complex than the examples shown above...

If you want to create a graph of your favorite application or library your self, get the script from here. I pulished the simple source code below. Graphviz is the only requirement. Usage is very simple, just pass an application or library as first parameter and the output image as second argument. The script will always create a PNG image:./dependencies.sh /usr/bin/emacs emacs.png
./dependencies.sh /usr/local/lib/libpodofo.so \

The code of the script is as follows: (Warning: the style sheet cuts of some lines, so better download the script from dependencies.sh)


# This is the maximum depth to which dependencies are resolved

# analyze a given file on its
# dependecies using ldd and write
# the results to a given temporary file
# Usage: analyze [OUTPUTFILE] [INPUTFILE]
function analyze
local OUT=$1
local IN=$2
local NAME=$(basename $IN)

for i in $LIST
if [ "$i" == "$NAME" ];
# This file was already parsed
# Put the file in the list of all files

if [ $DEPTH -ge $MAXDEPTH ];
echo "MAXDEPTH of $MAXDEPTH reached at file $IN."
echo "Continuing with next file..." # Fix by Marco Nelissen for the case that MAXDEPTH was reached DEPTH=$[$DEPTH - 1]

echo "Parsing file: $IN"


if [ $ELFRET != 0 ];
echo "ERROR: ELF reader returned error code $RET"
echo "ERROR:"
echo "Aborting..."
exit 1

DEPENDENCIES=$(cat $READELFTMPFILE | grep NEEDED | awk '{if (substr($NF,1,1) == "[") print substr($NF, 2, length($NF) - 2); else print $NF}')

if [ -n "$DEP" ];


if [ $LDDRET != 0 ];
echo "ERROR: ldd returned error code $RET"
echo "ERROR:"
echo "Aborting..."
exit 1

DEPPATH=$(grep $DEP $LDDTMPFILE | awk '{print $3}')
if [ -n "$DEPPATH" ];
echo -e " \"$NAME\" -> \"$DEP\";" >> $OUT
analyze $OUT $DEPPATH

# main #
if [ $# != 2 ];
echo "Usage:"
echo " $0 [filename] [outputimage]"
echo ""
echo "This tools analyses a shared library or an executable"
echo "and generates a dependency graph as an image."
echo ""
echo "GraphViz must be installed for this tool to work."
echo ""
exit 1
TMPFILE=$(mktemp -t)
LDDTMPFILE=$(mktemp -t)
if [ ! -e $INPUT ];
echo "ERROR: File not found: $INPUT"
echo "Aborting..."
exit 2
# Use either readelf or dump
# Linux has readelf, Solaris has dump
READELF=$(type readelf 2> /dev/null)
if [ $? != 0 ]; then
READELF=$(type dump 2> /dev/null)
if [ $? != 0 ]; then
echo Unable to find ELF reader
exit 1
READELF="dump -Lv"
READELF="readelf -d"

echo "Analyzing dependencies of: $INPUT"
echo "Creating output as: $OUTPUT"
echo ""

echo "digraph DependencyTree {" > $TMPFILE
echo " \"$(basename $INPUT)\" [shape=box];" >> $TMPFILE
analyze $TMPFILE "$INPUT"
echo "}" >> $TMPFILE
#cat $TMPFILE # output generated dotfile for debugging purposses
dot -Tpng $TMPFILE -o$OUTPUT

exit 0
Categories: FLOSS Project Planets

Python Software Foundation: Twisted Trial Ported to Python 3!

Planet Python - Fri, 2015-10-23 09:40
Twisted, as many of you know, is an asynchronous, or event driven networking framework written in Python (https://twistedmatrix.com/trac/wiki). Twisted has been around for about a decade, offers many features, including low-level primitives and high-level interfaces, and works with many protocols (including HTTP, XMPP, NNTP, IMAP, SSH, IRC, FTP). 
Twisted Logo Due to its maturity and complexity, Twisted requires a lot of time and effort to be completely ported to Python 3. Fortunately, the PSF was able to help fund some of this work; one recent result is the release of Twisted 15.4, which includes Twisted’s standard test-runner, Trial (codenamed "Trial by Fire"). The PSF Grant allowed core developer and Twisted release manager,
Amber (HawkOwl) Brown, to port Trial to Python 3. She recently sent the PSF this announcement: “Just wanting to let you all know that a Twisted with the PSF-funded Trial Py3 port is now released. And a little example of it in action:
https://asciinema.org/a/cthr9xezlt8mxg5dp0n73fzc9. Again, many thanks for accepting the grant proposal – the ability to dedicate a significant chunk of time to this work has meant it was completed well sooner than if the grant had not been accepted.” Due to certain differences between Python 3 and Python 2 (e.g., removal of ClassType and unbound methods), Amber tells us that the porting of Trial required a rewriting and retesting of the test suite loader. The work is mostly done and the current port duplicates most of Trial’s previous functionality with the exception of its distributed test runner (DistTrialRunner). Specifically, the PSF grant allowed Amber to perform the following steps: - Complete and test the Trial unittest loader  - Fix the remaining failing Trial tests   - Create a tool which runs only the portions of Twisted that have been ported to Python 3 for use in Twisted development   - Break up the port into smaller pieces, put them up for review, and address the review comments   - Merge the reviewed portions Trial’s features–a front-end, the ability to handle Deferreds and asynchronous tests, and the capacity to build testcase-duration reactors, make testing much easier. The Twisted team will now be able to use Trial for continued Python 3 porting, while users of Twisted will be able to test their codebases more easily as they port them to Python 3. Because of Trial, we can look forward to Twisted 15.5 in the near future (and hope to see more users' code ported to Python 3, as well). As Amber tells us, "15.5, coming soon, will come with another handful of ported modules, and the twistd application (a daemoniser + plugin runner, the recommended way of spawning long-running Twisted services)." The PSF sends its gratitude and congratulations to Amber Brown and the Twisted team on this important accomplishment.

To learn more about Twisted, the following websites, video talks, and tutorials are available: http://labs.twistedmatrix.com/ http://krondo.com/wp-content/uploads/2009/08/twisted-intro.html http://www.ibm.com/developerworks/library/l-twist1/ http://pyvideo.org/video/2597/twisted-mixing https://www.youtube.com/watch?v=_HZR7_ZBkYY

I would love to hear from readers. Please send feedback, comments, or blog ideas to me at msushi@gnosis.cx.
Categories: FLOSS Project Planets

OpenConcept: Tips for a Sustainable Drupal 7 & 8 Website

Planet Drupal - Fri, 2015-10-23 08:58

Stephanie Daniels sums it up well, "Optimized sites are better for the environment. That’s because they’re significantly faster, more usable, with content that’s optimized for SEO and user experience. It’s my belief that Drupal has all of the tools in place to create sustainable websites…if you just know where to look.".

If only I had Drupal back in 1995. That was the year I built my first website for a Fair Trade Retailer called Bridgehead. Back at this time, the Internet was a very different place. People were using the web at that point, but it wasn't embeded in our lives like it is now.

Even the ecological footprint of the Internet 20 years ago was pretty small. Sure, there was already a network of computers that spanned the globe, but there weren't the giant data centres that there are now.

There are over 1 million sites running Drupal right now, representing about 3% of the Internet. The Information and Communication Technology (ICT) sector is estimated to contributed around 2 to 2.5 per cent of global greenhouse gas (GHG) emissions according to the International Telecommunication Union. There is a nice breakdown of this energy consumption in the world's ICT. This is only growing as we find more ways to use the Internet to make our lives more convenient.

There are a few people in the web industry who are aware of this and are working to raise awareness of others. I've been inspired by both Mightybytes and Manoverboard who have been leading this discussion within the BCorporation community. This article is going to extend the work of Mightybytes in their 15 Ways to Optimize Drupal for Sustainable Web Design article as well as the post by Manoverboard in Creating a Responsible, Earth-Friendly Website. I don't want to repeat their work, but saw an opportunity to update a few things, particularly in line with Drupal 7 & 8.

Certainly with Google prioritizing speedy pages in their search rank many sites have started making performance a higher priority. The rise in mobile usage also is driving performance, as usually mobile devices have lower bandwidth than desktop devices.

In Drupal there is a lot that can be done on the front-end, the back-end, and on the server. With a good content strategy we can ensure that the content is easy to find, and simple to use. All of this will help reduce the time that a user needs to spend using your site, which will reduce it's total carbon emmissions.

Drupal Optimization

Here are some helpful tips to optimize your overall Drupal experience:

Remove unnecessary HTML to help the page load faster using the Fences module (7/8-dev). To change the to the lighter markup, make a copy of any tpl file that ships with the Fences module and add it to your custom theme. You can also make your own Fences-styled tpl files and place them in your theme by using the fences naming convention. Fences will automatically find them, and add them to the list available in the dropdown for field configuration.

Aggregate and compress your CSS and Javascript by enabling the Advanced CSS/JS Aggregation module (7/8-sandbox). You could just enable the default compression/aggregation code that comes with Core (Administer > Configuration > Performance), but there many advances in the Advanced CSS/JS Aggregation module which we feel will make your page load faster. There is a good explaination of how to move the JavaScript & CSS to the page footer in Drupal 7 to speed up the page load. In Drupal 8, Javascript by default runs in the footer. This module also allows sites to use Google's Content Delivery Network (CDN) to load jQuery. If a browser has already loaded a javascript file from a CDN, it will just use it's cached file rather than downloading it again.

An alternative module that uses Google's Closure Compiler webserver is minify which has fewer options and should be easier to set up. The Speedy module is another option.

Make sure you are delivering smaller images to your visitors using the Drupal Core's ImageCache module (7/8). This is especially important for mobile devices where the browser is rendering much smaller images. Page speed can be dramatically reduced by using big images that aren't optimized. Tools like TinyPNG can be useful to reduce image size before uploading them to your site.

There are so many reasons to design Mobile First, and using semantic HTML5 and modern CSS3. With Drupal we've been suggesting starting with a good base theme like Zen (7/8-patch) or Adaptive Theme (7/8-dev) for accessibility for years, but they also are great responsive platforms. Designing for a mobile device first forces organizations to prioritize what is most important to them and simplify their site. This can then be added to when a user is browsing your site with a big monitor and high bandwidth.

Use Scalor Vector Graphics (SVG) rather than PNGs or GIFs where possible. SVG files are usually very small, they can be written inline in HTML5 & CSS files, and they they scale without loosing clarity. This allows you to use the same image on your phone as you do on your desktop. Drupal 8 is replacing many of it's PNG files with SVG files for this purpose.

Today, LCD screens use the lest energy using a lighter colour palette. Of note, an old Cathode Ray Tube monitor will use about 200% more energy than a comparable LCD screen. So when designing your site, more than ever think about the advantages of a bit more white space.

Disable unnecessary and unused modules. There are modules like Devel (7/8-dev) that shouldn't be enabled on production site anyways for performance reasons. Drupal's statistics module can also slow down a page since it needs to write to the database for every page load. There are also modules like Views UI that are only needed when you are editing a View, so why not disable it by default. Some code from the enabled modules will be loaded with every page view, thus slowing down your site.

Many people visiting your site are probably skipping the home page and going directly to the content that the search engine sends them to. This is great for the user and also great for the environment. Make sure you've enabled the SEO Checklist module and follow the advice within it to ensure that search engines send visitors directly to the information they want.

Server-Level Optimization

For those more savvy with server maintenance:

Enable page and block cache (Administer > Configuration > Performance) in Drupal 7. There are a great many improvements in caching in Drupal 8 and sites with changing content will perform much better. Page caching and CSS/JS aggregation is enabled by default, so hopefully it will be employed by default by more sites in the future. There have also been huge page improvements in the dynamic page cache for all users which should help interactive sites and improvements for administrators.

You may also choose to compress the cached pages using here. This can also be done in Apache, so it really depends on how you configure your server, no point to compress them twice. Make sure to increase the cache lifetime in Drupal so that you are not having to regenerate the pages unless needed. If you want to go even farther, install Varnish and set up the Varnish module (7/8-dev). Varnish is a very powerful page caching tool that is very configurable. For some sites we recommend setting up a seperate Varnish server devoted to serving cached pages.

Memcached is a high-performance, distributed memory object caching system that can be used to speed up your Drupal site by alleviating database load. The Memcache module (7/8-dev) or Memcache Storage module is required to take full advantage of this, and Memcached can be run alongside Apache or on it's own server, depending on expected demands.

You should also look at optimizing your database on a regular basis. The DB Maintenace module (7/8-dev) uses cron to run MySQL's OPTIMIZE TABLE on a regular basis. Ideally you could do this with a cron script using MySQL commands in off-peak hours too.

echo "OPTIMIZE TABLE accesslog,cache,comments,node,users,watchdog;FLUSH TABLES;" |mysql -u user -ppasswd

There are a great many other suggestions from the community on how you can tune your server. There is an active community of Drupal developers interested in high performance configurations, it's worth checking out their ideas. There are also videos on MySQL performance improvements for Drupal.

In Drupal 7, install Alternative PHP Cache (APC) to and the APC module (7) to cache PHP code. For Drupal 8, look forward to using PHP7, which runs way faster, than earlier versions of PHP. Drupal 8 runs much faster in PHP7, but unfortunately, APC is not yet available in PHP7.

Think of using a Content Delivery Network (CDN) to deliver some of your content. A CDN serves content from a location that will be optimized for the visitor's location. Wim Leers has written a series of great posts on setting up the CDN module (7) to optimize your site.

Look into adopting HTTP/2 on your server because it offers performance improvements and may negate the advantages of aggregating CSS/JS files. At the moment there is great browser support for HTTP/2, but less than 2% of sites support this new protocol. Regardless, it is usually best to assume that less HTTP requests = faster page loading.

Sometimes though you just need to spend a bit more on faster hardware, more RAM and solid state drives. Having multiple servers can really help deal with busy sites.

Think about switching to a green hosting company. Look for a host that is using green energy and has a strong environmental policy. Your servers are running 24/7, so having a green host can have a significant impact on your CO2 output. Mightybytes has a blog and Manoverboard a White Paper about green hosting that are worth checking out.

Content Optimization

If your job is more catered towards the material shown on the site:

Think about your content. Could meaning be clearly conveyed with fewer images? Are the images optimized? Is content created using proper semantic markup that is styled using centralized (and cached) CSS files?

Andrew Boardman's blog on Manoverboard is great in encouraging us to keep it simple. Steve Krug's book Don’t Make Me Think contains principles that are "highly relevant to all digital interfaces not only for ease of use and human engagement but also in determining energy consumption that powers our online behaviours."

He also argues for archiving unused content. Users expect websites to contain fresh content and not to contain an active history of all pages that have ever been published. Fewer pages mean that there are more quality pages for search engines to index and that it takes less energy to maintain them.

Content should be findable. Users will benefit from sites that have a well considered navigational structure. Using structured taxonomies can also allow visitors to find related content. Enable Drupal's core search, or better yet set up Apache Solr and use the Apache Solr module to provide an amazing faceted search experience.

Don't use Flash. Aside from not working on many mobile devices, Flash is known to consume a lot of energy, which was one of the reasons that Apple used to not support Flash on iPhones. Use HTML5's <video> format which has huge accessibility advantages as well as it's environmental impact. There are of course other reasons not to rely on flash because of security or accessibility problems.

Evaluate Performance

Finally, when you've done all of your changes:

Don't trust that enabling these tools will work. Page optimization needs to be evaluated to determine that you are actually delivering faster pages. Yahoo's YSlow, Google's Insights & WebPageTest all offer means to evaluate web pages. Note that your performance on various pages may vary. Yahoo! also has a list of best practices that are worth considering.

Page speed will always vary based on load. Consider using the Apache HTTP server benchmarking tool to simulate how your website performs with a heavy page load. The Performance Logging and Monitoring module can help you track your performance over time as well.

It's also really worth taking a look at Mightybyte's EcoGrader tool to get a quick evaluation of some of these improvements on your site.

In the end, it isn't difficult to take the time to look over the suggestions in this post and make a difference for the sustainability of your website(s) and the environment. Regardless of your technical expertise, there are improvements to be made at any level of website development. All you need to do is use the tool's at your disposal.

Topic: Primary Image: 
Categories: FLOSS Project Planets

Clint Adams: Beware of typhoons or tsunamis

Planet Debian - Fri, 2015-10-23 05:39

The 12 member nations of the Trans-Pacific Partnership pact have agreed to prohibit demands that companies reveal software source code*, a step that appears aimed at curbing efforts by China to gain access to this sensitive information, The Yomiuri Shimbun has learned.

Source code is the confidential information for software and is a “blueprint” embedded in many commonly used products, such as vehicles, mobile phones and home appliances. Source code is usually tightly guarded because it conatins commands that make using the software easier.

China requires foreign companies operating there to hand over source code, a move that has sparked sharp criticism from many countries. Observers believe the decision by TPP participants to ban demands to reveal this code is intended to restrain China's move.

The TPP's electronic commerce chapter in principle prohibits the 12 member nations from demanding access to source code for mass-produced software. According to the Economy, Trade and Industry Ministry, the Japan-Mongolia economic partnership agreement signed in February contains a stipulation banning demands for such information, but there are very few other examples around the world.

Japan, the United States and other nations that are home to many information technology companies want to make the stipulation effectively a global standard, and they are considering whether to incorporate such a condition in economic partnership agreements that will be inked in the future.

Source code is an important corporate secret for development firms.

*Source code—A software program written in a language a computer understands. As well as containing expert details about the unique functions of the product, the software is essential for fixing glitches and making improvements. Hackers have attempted to access source code because gaining this information would make it easier to create viruses that could exploit any software defects. In the software business, it is rarely made public, as it is considered a corporate secret.

Categories: FLOSS Project Planets

Petter Reinholdtsen: "Free Culture" by @lessig - The background story for Creative Commons - new edition available

Planet Debian - Fri, 2015-10-23 05:10

Click here to buy the book.

In 2004, as the Creative Commons movement gained momentum, its creator Lawrence Lessig wrote the book Free Culture to explain the problems with increasing copyright regulation and suggest some solutions. I read the book back then and was very moved by it. Reading the book inspired me and changed the way I looked on copyright law, and I would love it if more people would read it too.

Because of this, I decided in the summer of 2012 to translate it to Norwegian Bokmål and publish it for those of my friends and family that prefer to read books in Norwegian. I translated the book using docbook and a gettext PO file, and a byproduct of this process is a new edition of the English original. I've been in touch with the author during by work, and he said it was fine with him if I also published an English version. So I decided to do so. Today, I made this edition available for sale on Lulu.com, for those interested in a paper book. This is the cover:

The Norwegian Bokmål version will be available for purchase in a few days. I also plan to publish a French version in a few weeks or months, depending on the amount of people with knowledge of French to join the translation project. So far there is only one active person, but the French book is almost completely translated but need some proof reading.

The book is also available in PDF, ePub and MOBI formats from my github project page. Note the ePub and MOBI versions have some formatting problems I believe is due to bugs in the docbook tool dbtoepub (Debian BTS issues #795842 and #796871), but I have not taken the time to investigate. I recommend the PDF and ePub version for now, as they seem to show up fine in the viewers I have available.

After the translation to Norwegian Bokmål was complete, I was able to secure some sponsoring from the NUUG Foundation to print the book. This is the reason their logo is located on the back cover. I am very grateful for their contribution, and will use it to give a copy of the Norwegian edition to members of the Norwegian Parliament and other decision makers here in Norway.

Categories: FLOSS Project Planets

Colm O hEigeartaigh: A certificate revocation security vulnerability in Java

Planet Apache - Fri, 2015-10-23 05:04
A few days ago, Oracle released a Critical Patch Update containing fixes for various security vulnerabilities. In particular, the update contained fixes for 25 security vulnerabilities in Java itself. One of them, CVE-2015-4868, was discovered by me and duly disclosed to Oracle earlier this year. This issue has now been fixed in this Critical Patch Update (and included in Java 1.8.0_65), and so I am free to describe it.

1) Background

I first noticed this issue in the context of signature validation of SOAP web service requests. A signed SOAP request involves using XML Signature to sign some part of the request, where the resulting Signature structure is inserted into the security header of the request. The Signature contains a KeyInfo Element, which references the (public) key to use to validate the request. The recipient must resolve the appropriate public key, establish trust in it, and use it to validate the signature.

A common use-case is when the certificate used to validate the signature is included directly in the request, by BASE-64 encoding it in the security header. Optionally, the full certificate chain can be included instead. The recipient must take the certificates and establish a trust chain using a CA certificate stored in a local truststore, which is then validated.

However, what if the signing certificate has been revoked by the issuing CA? In this case, we can specify a Certificate Revocation List, and include it as part of the validation of the trust chain.

2) The vulnerability

Now to the vulnerability. Under the more usual use-case of just including the signing certificate in the security header, and establishing a trust-chain using a local truststore and CRL file, everything was working fine. Namely, if the signing certificate was trusted, but revoked, then the CertPath validation failed. However, if the issuing certificate of the signing certificate was also included in the security header, then CRL validation was not failing! This vulnerability exists in a range of JDK 8 versions prior to 1.8.0_65. It does not exist prior to JDK 8.

To see how this works using the Java CertPathValidator API, I created a simple maven-based unit test in github:
  • java.crls - A testcase that show how to include a CRL when validating the certificate path of a certificate.
The test has a JUnit failure assertion that asserts that the CertPathValidator validation should fail (as the signing certificate has been revoked). However, this failure assertion is not met when run locally with Java 1.8.0_51. With a Java version post-1.8.0_65 the failure assertion is met, and the test passes.
Categories: FLOSS Project Planets

Looking at some crashers fixed this week

Planet KDE - Fri, 2015-10-23 04:07

Some of the feedback we got, is that we should blog more about how we improve the quality, what kind of bugs we fixed. So today I want to do that with an in-depth explanation of four crash reports I looked at and fixed this week. All of them will go be part of the upcoming 5.4.3 release. All of them were related to QtQuick with three of them being caused by a problem in QtQuick and one caused by a workaround for a QtQuick problem. As I explained in my Monday blog post we are getting hit by issues in the libraries we use, in this case QtQuick.

Closing glxgears crashes KWin

The first issue was communicated to me through IRC. After a small investigation together with the user we figured out the condition to crash it and how to reproduce it:
1. Use an aurorae window decoration theme (e.g. Plastik)
2. Open glxgears
3. close glxgears through the close button

This got reported as Bug 346857 and was nothing new to us: we have had similar problems before, which makes it a little bit sad. The problem here is that glxgears doesn’t speak the close window protocol. Normally when you click the close button the window isn’t closed directly, but the window gets notified “please close your window”. So the mechanism is asynchronous. This also explains why such an issue has not been detected during the testing: it’s not happening with default decoration and it’s not happening with “normal” applications. It can only be reproduced with applications which do not behave correctly.

So what’s the difference in this case? KWin handles the destruction in a synchronous way which causes the decoration to be destroyed in direct result of the mouse click. When the decoration is destroyed the QtQuick scene driving the decoration is also destroyed and it looks like Qt doesn’t like that:

<code>#0 0x00007ffff50fd107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff50fe4e8 in __GI_abort () at abort.c:89 #2 0x00007ffff5de8291 in qt_message_fatal (context=..., message=...) at global/qlogging.cpp:1578 #3 0x00007ffff5de495c in QMessageLogger::fatal (this=0x7fffffff8ca0, msg=0x7ffff6104270 "ASSERT: \"%s\" in file %s, line %d") at global/qlogging.cpp:781 #4 0x00007ffff5dddb90 in qt_assert (assertion=0x7ffff67df129 "context() &amp;&amp; engine()", file=0x7ffff67df0e4 "qml/qqmlboundsignal.cpp", line=183) at global/qglobal.cpp:2966 #5 0x00007ffff6667fe7 in QQmlBoundSignalExpression::function (this=0xf56080) at qml/qqmlboundsignal.cpp:183 #6 0x00007ffff6667d4c in QQmlBoundSignalExpression::sourceLocation (this=0xf56080) at qml/qqmlboundsignal.cpp:155 #7 0x00007ffff663f1fb in QQmlData::destroyed (this=0x873d90, object=0xf54eb0) at qml/qqmlengine.cpp:1709 #8 0x00007ffff663cf6b in QQmlData::destroyed (d=0x873d90, o=0xf54eb0) at qml/qqmlengine.cpp:674 #9 0x00007ffff605c6e9 in QObject::~QObject (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at kernel/qobject.cpp:912 #10 0x00007ffff7265df9 in QQuickItem::~QQuickItem (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at items/qquickitem.cpp:2224 #11 0x00007ffff7324866 in QQuickMouseArea::~QQuickMouseArea (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at items/qquickmousearea.cpp:439 #12 0x00007ffff72d69c5 in QQmlPrivate::QQmlElement&lt;QQuickMouseArea&gt;::~QQmlElement (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:98 #13 0x00007ffff72d69fa in QQmlPrivate::QQmlElement&lt;QQuickMouseArea&gt;::~QQmlElement (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:98 #14 0x00007ffff605e516 in QObjectPrivate::deleteChildren (this=0xf54c90) at kernel/qobject.cpp:1946 #15 0x00007ffff605cb80 in QObject::~QObject (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at kernel/qobject.cpp:1024 #16 0x00007ffff7265df9 in QQuickItem::~QQuickItem (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at items/qquickitem.cpp:2224 #17 0x00007ffff72c3e22 in QQuickRectangle::~QQuickRectangle (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at items/qquickrectangle_p.h:128 #18 0x00007ffff72d6357 in QQmlPrivate::QQmlElement&lt;QQuickRectangle&gt;::~QQmlElement (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:98 #19 0x00007ffff72d638c in QQmlPrivate::QQmlElement&lt;QQuickRectangle&gt;::~QQmlElement (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:98 #20 0x00007ffff736a976 in QQuickView::~QQuickView (this=0x6b1980, __in_chrg=&lt;optimized out&gt;) at items/qquickview.cpp:225 #21 0x00007ffff736a9d2 in QQuickView::~QQuickView (this=0x6b1980, __in_chrg=&lt;optimized out&gt;) at items/qquickview.cpp:227 </code>

Now in order to never have that happen again I created a test application and reported a bugreport against Qt. And of course we worked around the problem by delaying the handling of the close to the next event cycle. Now you might wonder how it’s possible that we allowed such a regression to sneak in again given that we had seen it before? Well that’s easily explained, up until recently we were not able to run full tests against KWin. We might have been able to unit test this area, but it would have passed, this issue needed an integration test. And that’s what I added now, so that we won’t hit it ever again. It’s probably the weirdest auto test I have ever written, involving starting glxgears (thanks to our sysadmins for installing it for this test case!), simulating the mouse click on the close button and ensuring glxgears closes without crashing KWin.

Crash when opening window decorations configuration module

The second crash I run into directly after investigating the first one. I wanted to switch back to Breeze decoration but couldn’t because the config module crashed directly. This was bug 344278 – a really nasty one with 74 duplicates. We had wonderful crash traces, but missed the important part about how to reproduce it. From the crash trace alone we were not able to figure out what’s going on. Well we saw some aspects but it wasn’t enough to properly investigate.

Now alas I had a 100 % sure way to reproduce the problem and also understood what’s going on. So here the actual steps to reproduce:
1. Open Window decoration configuration menu
2. Download many themes, many of them, the more the better
3. Select a theme which name’s first latter is far away from “B”, e.g. Plastik.
4. Apply and quit
5. Open window decoration configuration menu again

And boom! What happens is that we load all decorations and put them into a ListView, then we select the theme the user is currently using and ensure it’s centered in the list view. This results in the list view scrolling. ListView has a cache of elements and if you have too many it will throw out other elements. So our Breeze deco which gets created at the start (early in alphabet, will be shown) is kicked out again when selecting Plastik if there are too many decorations. This is the requirement to have many themes installed and also to select one far down in the alphabet. With anything else you won’t trigger it.

The bug itself got triggered through Breeze decoration because there is a Property animation running which triggers another update on the decoration after it has been kicked out. It accesses a member which got destroyed by the QtQuick engine.

All of that also means that the crash would not have been triggered if that code would have been e.g. in Oxygen and not in Breeze. Because then it would not have hit. Also just scrolling in the list after it loaded even if you have many installed, won’t trigger the crash, because then the animation is no longer running. It’s only running after loading in the preview. What I want to show here is that this is an extremely hidden corner case to find. You must have exactly the same conditions to trigger it. Given that I’m also surprised that we have so many duplicates for the report.

So how to fix it? Obvious idea: one could disable the anyway not visible animation in Breeze. But that’s not a fix, that’s just a workaround and doesn’t solve the actual problem. Other decorations might trigger that again. So we need to understand what’s going on. What we knew is that the Decoration triggers an update and crashes because the DecorationBridge is no longer valid. But that’s impossible! The contract of the KDecoration API is that the DecorationBridge will always be valid if there’s a Decoration. So how could the contract break?

For this we need to look into how the QtQuick code for rendering the previews works. Each Decoration is wrapped by a PreviewItem and each decoration gets it’s own DecorationBridge provided by a PreviewBridge. The PreviewBridge is directly constructed through QtQuick, the Decoration is loaded later on. What is now interesting is the tear down. When the PreviewItem gets destroyed by QtQuick it doesn’t delete the Decoration directly, but delays it to the next event cycle. So the Decoration outlives the QtQuick items. When the PreviewItem gets destroyed by QtQuick also the PreviewBridge gets destroyed by QtQuick and thus we have a Decoration which is still alive, but the PreviewBridge isn’t. Why was it done that way? Well to prevent crashers caused by QtQuick. So our workaround for a crash just introduced a new one. Meh.

The solution now is to also delay the deconstruction of the PreviewBridge to the next event cycle. I hope this does not again create a new crash.

Crash when exiting Screens configuration module

The third issue I looked into was also reported to me in response to my Monday’s blog post. This one was supposed to be fixed in Qt 5.5, but wasn’t. It has a clear way to reproduce it:
1. Open Systemsettings
2. Go to “Display Configuration”
3. Click “All Settings” to go back to overview

According to our users that should crash it. Just it doesn’t. This raised my interest – also that it has 73 duplications which makes it rather important. I know the user who reported this to me and know that I can fully believe what he tells me. So this crash raised my interest. It also has a very interesting crash trace:

<code>#0 0x00007ffff2e48d59 in QQuickItemPrivate::addToDirtyList (this=0xdbdcc0) at /mnt/AUR/qt5-declarative-git/src/qt5-declarative/src/quick/items/qquickitem.cpp:5610 #1 0x00007ffff2e48e43 in QQuickItemPrivate::dirty (this=0xdbdcc0, type=&lt;optimized out&gt;) at /mnt/AUR/qt5-declarative-git/src/qt5-declarative/src/quick/items/qquickitem.cpp:5594 #2 0x00007ffff2e496cd in QQuickItem::update (this=0xdbdc40) at /mnt/AUR/qt5-declarative-git/src/qt5-declarative/src/quick/items/qquickitem.cpp:4088 #3 0x00007ffff2e56c0d in QQuickItem::qt_static_metacall (_o=&lt;optimized out&gt;, _c=&lt;optimized out&gt;, _id=&lt;optimized out&gt;, _a=&lt;optimized out&gt;) at .moc/moc_qquickitem.cpp:597 #4 0x00007ffff45f2ae1 in QObject::event (this=this@entry=0xdbdc40, e=e@entry=0x7fffc41f80b0) at kernel/qobject.cpp:1239 #5 0x00007ffff2e53a63 in QQuickItem::event (this=0xdbdc40, ev=0x7fffc41f80b0) at /mnt/AUR/qt5-declarative-git/src/qt5-declarative/src/quick/items/qquickitem.cpp:7294 #6 0x00007ffff6087d94 in QApplicationPrivate::notify_helper (this=this@entry=0x681dd0, receiver=receiver@entry=0xdbdc40, e=e@entry=0x7fffc41f80b0) at kernel/qapplication.cpp:3717 #7 0x00007ffff608d2c8 in QApplication::notify (this=0x7fffffffe4a0, receiver=0xdbdc40, e=0x7fffc41f80b0) at kernel/qapplication.cpp:3500 #8 0x00007ffff45c49dc in QCoreApplication::notifyInternal (this=0x7fffffffe4a0, receiver=0xdbdc40, event=event@entry=0x7fffc41f80b0) at kernel/qcoreapplication.cpp:965 #9 0x00007ffff45c7dea in sendEvent (event=0x7fffc41f80b0, receiver=&lt;optimized out&gt;) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:224 #10 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x681430) at kernel/qcoreapplication.cpp:1593 #11 0x00007ffff45c8230 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1451 #12 0x00007ffff4617f63 in postEventSourceDispatch (s=0x6d7aa0) at kernel/qeventdispatcher_glib.cpp:271 #13 0x00007fffefcce9fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #14 0x00007fffefccece0 in ?? () from /usr/lib/libglib-2.0.so.0 #15 0x00007fffefcced8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #16 0x00007ffff4617fd7 in QEventDispatcherGlib::processEvents (this=0x6d5850, flags=...) at kernel/qeventdispatcher_glib.cpp:418 #17 0x00007ffff45c339a in QEventLoop::exec (this=this@entry=0x7fffffffe380, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #18 0x00007ffff45cb23c in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1229 #19 0x00007ffff592cbf4 in QGuiApplication::exec () at kernel/qguiapplication.cpp:1528 #20 0x00007ffff6084bb5 in QApplication::exec () at kernel/qapplication.cpp:2977 #21 0x000000000040f52b in main (argc=1, argv=&lt;optimized out&gt;) at /mnt/AUR/systemsettings-git/src/systemsettings/app/main.cpp:55 </code>

The interesting part here is that it’s completely inside Qt. We come from the event loop and an event is handled inside Qt and crashes. No code of the control module is executed in this trace any more.

But why am I not able to reproduce? After all there are so many users hitting it. I have the same Qt version, so it should crash. That I figured it out was pure chance. I remembered that the user has an NVIDIA system and I verified that this is still the case. I have an Intel system. So why is that important? For NVIDIA QtQuick uses threaded rendering, while for Mesa it uses the main gui thread for rendering. I had seen in the past that with threaded rendering destruction might be moved to the next event cycle. So easy thing to test:
QSG_RENDER_LOOP=threaded systemsettings5 and follow the reproduction steps and boom! Yay, I have a test case. Following the old saying: “consider a bug fixed when a developer is able to reproduce” the hardest way was solved.

So I started investigating. Let’s try with kcmshell5 instead of systemsettings. Hmm doesn’t crash. Let’s try with kscreen’s test application instead of systemsettings. Hmm, doesn’t crash. So something in systemsettings must trigger it! And I started reading code and read and read, tried here something, tried there something and come to the conclusion: systemsettings is not doing anything wrong.

Given that it must be the QtQuick code of the screen configuration. After some trials I had a minimal derivation to the QtQuick code which didn’t crash any more. Here again helped previous experience with QtQuick related crashers: I saw some usage of QtGraphicalEffects and remembered that this one used to crash KWin with the Breeze Aurorae Theme prior to Plasma 5.2. Removing the OpacityMask didn’t crash. Yay! So how to get that into a fix? The solution was actually in the debug output of QtQuick:
QSGDefaultLayer::bind: ShaderEffectSource: ‘recursive’ must be set to true when rendering recursively.

So obviously I set this missing recursive on the OpacityMask. Hmm, compile error, that doesn’t exist. So let’s make it non recursive and there we go, it doesn’t crash any more.

I would love to report this to Qt, but so far I failed with creating a simple test case. Just like with my testing with kcmshell5 and the kscreen test application I’m not able to hit the condition and I haven’t figured out yet what is different in systemsettings.

Opening effects configuration twice crashes

The last issue to look at was triggered through the previous issue. During review it was pointed out that there are more QtQuick configuration modules which crash in similar ways. So I tried them all and hit a crash if:
1. Open Systemsettings
2. Go to Desktop Behavior
3. Click Desktop Effects
4. Click All Settings
5. Repeat steps 2 and 3

Again a very interesting back trace:

<code>#0 0x00007ffff28e7107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff28e84e8 in __GI_abort () at abort.c:89 #2 0x00007ffff35d2291 in qt_message_fatal (context=..., message=...) at global/qlogging.cpp:1578 #3 0x00007ffff35ce95c in QMessageLogger::fatal (this=0x7fffffff3920, msg=0x7ffff38ee270 "ASSERT: \"%s\" in file %s, line %d") at global/qlogging.cpp:781 #4 0x00007ffff35c7b90 in qt_assert (assertion=0x7ffff1f9276a "value.isString()", file=0x7ffff1f92710 "jsruntime/qv4runtime.cpp", line=439) at global/qglobal.cpp:2966 #5 0x00007ffff1ddb5eb in QV4::RuntimeHelpers::convertToObject (engine=0x139a400, value=...) at jsruntime/qv4runtime.cpp:439 #6 0x00007ffff1ddcc6e in QV4::Runtime::getProperty (engine=0x139a400, object=..., nameIndex=136) at jsruntime/qv4runtime.cpp:682 #7 0x00007ffff1dca362 in QV4::Moth::VME::run (this=0x7fffffff41d7, engine=0x139a400, code=0x7fffcc15f830 "\357\230\334\361\377\177", storeJumpTable=0x0) at jsruntime/qv4vme_moth.cpp:487 #8 0x00007ffff1dce656 in QV4::Moth::VME::exec (engine=0x139a400, code=0x7fffcc15f6c8 "\366\251\334\361\377\177") at jsruntime/qv4vme_moth.cpp:925 #9 0x00007ffff1d58eb3 in QV4::SimpleScriptFunction::call (that=0x7fffd3424010, callData=0x7fffd3424018) at jsruntime/qv4functionobject.cpp:564 #10 0x00007ffff1c93e14 in QV4::Object::call (this=0x7fffd3424010, d=0x7fffd3424018) at ../../include/QtQml/5.5.1/QtQml/private/../../../../../src/qml/jsruntime/qv4object_p.h:305 #11 0x00007ffff1e93cac in QQmlJavaScriptExpression::evaluate (this=0x2b7a690, context=0x1392ad0, function=..., callData=0x7fffd3424018, isUndefined=0x7fffffff4553) at qml/qqmljavascriptexpression.cpp:158 #12 0x00007ffff1e939a5 in QQmlJavaScriptExpression::evaluate (this=0x2b7a690, context=0x1392ad0, function=..., isUndefined=0x7fffffff4553) at qml/qqmljavascriptexpression.cpp:116 #13 0x00007ffff1e9c484 in QQmlBinding::update (this=0x2b7a670, flags=...) at qml/qqmlbinding.cpp:194 #14 0x00007ffff1e9cfac in QQmlBinding::update (this=0x2b7a670) at qml/qqmlbinding_p.h:97 #15 0x00007ffff1e9cab2 in QQmlBinding::expressionChanged (e=0x2b7a690) at qml/qqmlbinding.cpp:260 #16 0x00007ffff1e94d67 in QQmlJavaScriptExpressionGuard_callback (e=0x15ddbb0) at qml/qqmljavascriptexpression.cpp:361 #17 0x00007ffff1e72d0f in QQmlNotifier::emitNotify (endpoint=0x0, a=0x0) at qml/qqmlnotifier.cpp:94 #18 0x00007ffff1dfb3f6 in QQmlData::signalEmitted (object=0x33914f0, index=30, a=0x0) at qml/qqmlengine.cpp:763 #19 0x00007ffff384d31e in QMetaObject::activate (sender=0x33914f0, signalOffset=29, local_signal_index=1, argv=0x0) at kernel/qobject.cpp:3599 #20 0x00007ffff1df7906 in QQmlVMEMetaObject::activate (this=0x3391720, object=0x33914f0, index=44, args=0x0) at qml/qqmlvmemetaobject.cpp:1325 #21 0x00007ffff1df5436 in QQmlVMEMetaObject::metaCall (this=0x3391720, c=QMetaObject::WriteProperty, _id=42, a=0x7fffffff6860) at qml/qqmlvmemetaobject.cpp:841 #22 0x00007ffff1bb7432 in QAbstractDynamicMetaObject::metaCall (this=0x3391720, c=QMetaObject::WriteProperty, _id=42, a=0x7fffffff6860) at /home/martin/src/qt5/qtbase/include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qobject_p.h:421 #23 0x00007ffff1df5e91 in QQmlVMEMetaObject::metaCall (this=0x2ca1900, c=QMetaObject::WriteProperty, _id=42, a=0x7fffffff6860) at qml/qqmlvmemetaobject.cpp:969 #24 0x00007ffff1bb7432 in QAbstractDynamicMetaObject::metaCall (this=0x2ca1900, c=QMetaObject::WriteProperty, _id=42, a=0x7fffffff6860) at /home/martin/src/qt5/qtbase/include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qobject_p.h:421 #25 0x00007ffff3817ce1 in QMetaObject::metacall (object=0x33914f0, cl=QMetaObject::WriteProperty, idx=42, argv=0x7fffffff6860) at kernel/qmetaobject.cpp:294 #26 0x00007ffff1e14605 in QQmlPropertyPrivate::write (object=0x33914f0, property=..., value=..., context=0x3391390, flags=...) at qml/qqmlproperty.cpp:1308 #27 0x00007ffff1e13f47 in QQmlPropertyPrivate::writeValueProperty (object=0x33914f0, core=..., value=..., context=0x3391390, flags=...) at qml/qqmlproperty.cpp:1237 #28 0x00007ffff1e163ab in QQmlPropertyPrivate::writeBinding (object=0x33914f0, core=..., context=0x3391390, expression=0x3391bd0, result=..., isUndefined=false, flags=...) at qml/qqmlproperty.cpp:1597 #29 0x00007ffff1e9c567 in QQmlBinding::update (this=0x3391bb0, flags=...) at qml/qqmlbinding.cpp:198 #30 0x00007ffff1e9cfac in QQmlBinding::update (this=0x3391bb0) at qml/qqmlbinding_p.h:97 #31 0x00007ffff1e9cab2 in QQmlBinding::expressionChanged (e=0x3391bd0) at qml/qqmlbinding.cpp:260 #32 0x00007ffff1e94d67 in QQmlJavaScriptExpressionGuard_callback (e=0x15dd948) at qml/qqmljavascriptexpression.cpp:361 #33 0x00007ffff1e72d0f in QQmlNotifier::emitNotify (endpoint=0x0, a=0x0) at qml/qqmlnotifier.cpp:94 #34 0x00007ffff1dfb3f6 in QQmlData::signalEmitted (object=0x3391fc0, index=31, a=0x0) at qml/qqmlengine.cpp:763 #35 0x00007ffff384d31e in QMetaObject::activate (sender=0x3391fc0, signalOffset=31, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3599 #36 0x00007ffff384d120 in QMetaObject::activate (sender=0x3391fc0, m=0x7ffff2688b20 &lt;QQuickLoader::staticMetaObject&gt;, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3578 #37 0x00007ffff2432687 in QQuickLoader::itemChanged (this=0x3391fc0) at .moc/moc_qquickloader_p.cpp:321 #38 0x00007ffff2431370 in QQuickLoaderPrivate::incubatorStateChanged (this=0x2ca0700, status=QQmlIncubator::Ready) at items/qquickloader.cpp:666 #39 0x00007ffff24312e4 in QQuickLoaderIncubator::statusChanged (this=0x30f9e70, status=QQmlIncubator::Ready) at items/qquickloader.cpp:654 #40 0x00007ffff1e1f2ea in QQmlIncubatorPrivate::changeStatus (this=0x30f9e90, s=QQmlIncubator::Ready) at qml/qqmlincubator.cpp:701 #41 0x00007ffff1e1eab7 in QQmlIncubatorPrivate::incubate (this=0x30f9e90, i=...) at qml/qqmlincubator.cpp:368 #42 0x00007ffff1e1dd0e in QQmlEnginePrivate::incubate (this=0x13882d0, i=..., forContext=0x30f9db0) at qml/qqmlincubator.cpp:87 #43 0x00007ffff1e1a6d3 in QQmlComponent::create (this=0x15bfe90, incubator=..., context=0x2ca7160, forContext=0x0) at qml/qqmlcomponent.cpp:1068 #44 0x00007ffff24317a4 in QQuickLoaderPrivate::_q_sourceLoaded (this=0x2ca0700) at items/qquickloader.cpp:714 #45 0x00007ffff2430f10 in QQuickLoaderPrivate::load (this=0x2ca0700) at items/qquickloader.cpp:597 #46 0x00007ffff24319bf in QQuickLoader::componentComplete (this=0x3391fc0) at items/qquickloader.cpp:806 #47 0x00007ffff1ead859 in QQmlObjectCreator::finalize (this=0x31869c0, interrupt=...) at qml/qqmlobjectcreator.cpp:1207 #48 0x00007ffff1e1a094 in QQmlComponentPrivate::complete (enginePriv=0x13882d0, state=0x30b89a0) at qml/qqmlcomponent.cpp:928 #49 0x00007ffff1e1a17c in QQmlComponentPrivate::completeCreate (this=0x30b8900) at qml/qqmlcomponent.cpp:964 #50 0x00007ffff1e1a12c in QQmlComponent::completeCreate (this=0x1544040) at qml/qqmlcomponent.cpp:957 #51 0x00007ffff1e19953 in QQmlComponent::create (this=0x1544040, context=0x2bdd5f0) at qml/qqmlcomponent.cpp:791 #52 0x00007ffff24396e6 in QQuickView::continueExecute (this=0x134d440) at items/qquickview.cpp:476 #53 0x00007ffff2438617 in QQuickViewPrivate::execute (this=0x15c38c0) at items/qquickview.cpp:124 #54 0x00007ffff2438a2c in QQuickView::setSource (this=0x134d440, url=...) at items/qquickview.cpp:253 #55 0x00007fffd5c20a65 in KWin::Compositing::EffectView::init (this=0x134d440, type=KWin::Compositing::EffectView::DesktopEffectsView) at /home/martin/src/kf5/kde/workspace/kwin/kcmkwin/kwincompositing/model.cpp:613 </code>

Like in the previous example it’s a crash deep down in Qt. The first code related to code we distribute is at stack position 55. So again I needed to experiment to figure out the minimal code which triggers the crash and after some trials I figured out what causes it: setting root context properties. After reworking this to no longer needing a context property, it doesn’t crash any more.

Again this should be reported to Qt, bug so far I failed to create a simple example demonstrating the problem Of course setting a root context property works in my examples. If one of my readers have an idea what’s so special about systemsettings to trigger it, please let me know so that I can report bugs against Qt.


As we can see with these four cases: we are hit by issues further down in the stack. We can work around them, but this comes with a cost as it doesn’t fix the actual problem. Some of the problems are real corner cases, hardware dependent and cannot be reproduced by all developers.

Categories: FLOSS Project Planets

Jonathan Riddell Stands Down as Release Manager of Kubuntu

Planet KDE - Fri, 2015-10-23 03:51

With 15.10 successfully released we’re sorry to announce that Jonathan Riddell, the founder of Kubuntu, has decided to step down as release manager.

“Making Kubuntu over the last 10 years has been a fantastic journey. Even since I first heard about a spaceman making a Linux distro using Debian but faster release cycles I’ve known this would be something important and wanted KDE to be part of it. Bringing together KDE and Ubuntu has created the best operating system we can and the best community to work on it.

The life of an international freedom fighter is a fun one, I’ve traveled the world on private jet to meet extraordinary people and see amazing places. I watched monkeys swing from the network cables of Bengaluru and raced motorcycles through the slums of Kano. I was a a bit put out to be attacked by pirates in the Carribean but the help of the Kubuntu community and wider Ubuntu community helped me come back.

Community made open source software needs people to be able to take out what they’ve put in. Ubuntu’s licences and policies enforce this. However for the last three years Ubuntu’s main sponsor Canonical has had a policy contrary to this and after much effort to try to rectify this it’s clear that isn’t going to happen. The Ubuntu leadership seems compliant with this so I find myself unable to continue helping a project that won’t obey its own community rules and I need to move on. I won’t be going far, I’ll be helping out in KDE more, the original and best end-user free software community who have always been wonderful.”

You can see his full announcement here: https://lists.ubuntu.com/archives/kubuntu-devel/2015-October/010014.html
Categories: FLOSS Project Planets
Syndicate content