Hello The next releases of Config::Model will deprecate 2 (mis)features:

• Experience level: trying to filter out configuration parameter based on arbitrary experience is a bad idea. This may confuse user by hiding parameter without obvious way to show them back. (actually with the options menu on the graphical interface, but that s too easy to miss)
• Preset value: this feature provides a way to specify a default value at runtime. This is now provided with the configuration layer.

The behavior of cme check will not change. People using cme edit with the GUI will see many more configuration parameters. All the best

Thanks to the work of the Alioth admins and the DSA team, single sign-on services are back online. Everyone will again be able to register for DebConf14 according to the steps described on this page.

An issue with the integration between alioth.debian.org and sso.debian.org is currently preventing people other than Debian developers from logging in to the DebConf website for registration. We apologize for the inconvenience. Administrators are working to resolve the issue as quickly as possible; we will update this blog once the problem has been resolved. In the meantime, Debian developers can continue to register using their debian.org SSO credentials.

If you're looking to get started at packaging free software for Debian, you should start with the excellent New Maintainers' Guide or the Introduction to Debian Packaging on the Debian wiki. Once you know the basics, or if you prefer to learn by example, you may be interested in the full walkthrough which follows. We will look at the contents of three simple packages.

node-libravatar This package is a node.js library for the Libravatar service. Version 2.0.0-3 of that package contains the following files in its debian/ directory:

• changelog
• compat
• control
• copyright
• docs
• node-libravatar.install
• rules
• source/format
• watch

debian/control

Source: node-libravatar
Priority: extra
Maintainer: Francois Marier <francois@debian.org>
Build-Depends: debhelper (>= 9)
Standards-Version: 3.9.4
Section: web
Homepage: https://github.com/fmarier/node-libravatar
Vcs-Git: git://git.debian.org/collab-maint/node-libravatar.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/node-libravatar.git;a=summary
Package: node-libravatar
Architecture: all
Depends: $ shlibs:Depends , $ misc:Depends , nodejs
Description: libravatar library for NodeJS
 This library allows web application authors to make use of the free Libravatar
 service (https://www.libravatar.org). This service hosts avatar images for
 users and allows other sites to look them up using email addresses.
 .
 node-libravatar includes full support for federated avatar servers.

This is probably the most important file since it contains the bulk of the metadata about this package. Maintainer is a required field listing the maintainer of that package, which can be a person or a team. It only contains a single value though, any co-maintainers will be listed under the optional Uploaders field. Build-Depends lists the packages which are needed to build the package (e.g. a compiler), as opposed to those which are needed to install the binary package (e.g. a library it uses). Standards-Version refers to the version of the Debian Policy that this package complies with. The Homepage field refers to the upstream homepage, whereas the Vcs-* fields point to the repository where the packaging is stored. If you take a look at the node-libravatar packaging repository you will see that it contains three branches:

• upstream is the source as it was in the tarball downloaded from upstream.
• master is the upstream branch along with all of the Debian customizations.
• pristine-tar is unrelated to the other two branches and is used by the pristine-tar tool to reconstitute the original upstream tarball as needed.

After these fields comes a new section which starts with a Package field. This is the definition of a binary package, not to be confused with the Source field at the top of this file, which refers to the name of the source package. In this particular example, they are both the same and there is only one of each, however this is not always the case, as we'll see later. Inside that binary package definition, lives the Architecture field which is normally one of these two:

• all for a binary package that will work on all architectures but only needs to be built once
• any for a binary package that will work everywhere but that will need to be built separately for each architecture

Finally, the last field worth pointing out is the Depends field which lists all of the runtime dependencies that the binary package has. This is what will be pulled in by apt-get when you apt-get install node-libravatar. The two variables will be substituted later by debhelper.

debian/changelog

node-libravatar (2.0.0-3) unstable; urgency=low
  * debian/watch: poll github directly
  * Bump Standards-Version up to 3.9.4
 -- Francois Marier <francois@debian.org>  Mon, 20 May 2013 12:07:49 +1200
node-libravatar (2.0.0-2) unstable; urgency=low
  * More precise license tag and upstream contact in debian/copyright
 -- Francois Marier <francois@debian.org>  Tue, 29 May 2012 22:51:03 +1200
node-libravatar (2.0.0-1) unstable; urgency=low
  * New upstream release
    - new non-backward-compatible API
 -- Francois Marier <francois@debian.org>  Mon, 07 May 2012 14:54:19 +1200
node-libravatar (1.1.1-1) unstable; urgency=low
  * Initial release (Closes: #661771)
 -- Francois Marier <francois@debian.org>  Fri, 02 Mar 2012 15:29:57 +1300

This may seem at first like a mundane file, but it is very important since it is the canonical source of the package version (2.0.0-3 in this case). This is the only place where you need to bump the package version when uploading a new package to the Debian archive. The first line also includes the distribution where the package will be uploaded. It is usually one of these values:

• unstable for the vast majority of uploads
• stable for uploads that have been approved by the release maintainers and fix serious bugs in the stable version of Debian
• stable-security for security fixes to the stable version of Debian that cannot wait until the next stable point release and have been approved by the security team

Packages uploaded to unstable will migrate automatically to testing provided that a few conditions are met (e.g. no release-critical bugs were introduced). The length of time before that migration is influenced by the urgency field (low, medium or high) in the changelog entry. Another thing worth noting is that the first upload normally needs to close an ITP (Intent to Package) bug.

debian/rules

#!/usr/bin/make -f
# -*- makefile -*-
%:
    dh $@ 
override_dh_auto_test:

As can be gathered from the first two lines of this file, this is a Makefile. This is what controls how the package is built. There's not much to see and that's because most of its content is automatically added by debhelper. So let's look at it in action by building the package:

$ git buildpackage -us -uc

and then looking at parts of the build log (../node-libravatar_2.0.0-3_amd64.build):

 fakeroot debian/rules clean
dh clean 
   dh_testdir
   dh_auto_clean
   dh_clean

One of the first things we see is the debian/rules file being run with the clean target. To find out what that does, have a look at the dh_auto_clean which states that it will attempt to delete build residues and run something like make clean using the upstream Makefile.

 debian/rules build
dh build 
   dh_testdir
   dh_auto_configure
   dh_auto_build

Next we see the build target being invoked and looking at dh_auto_configure we see that this will essentially run ./configure and its equivalents. The dh_auto_build helper script then takes care of running make (or equivalent) on the upstream code. This should be familiar to anybody who has ever built a piece of free software from scratch and has encountered the usual method for building from source:

./configure
make
make install

Finally, we get to actually build the .deb:

 fakeroot debian/rules binary
dh binary 
   dh_testroot
   dh_prep
   dh_installdirs
   dh_auto_install
   dh_install
...
   dh_md5sums
   dh_builddeb
dpkg-deb: building package  node-libravatar' in  ../node-libravatar_2.0.0-3_all.deb'.

Here we see a number of helpers, including dh_auto_install which takes care of running make install. Going back to the debian/rules, we notice that there is manually defined target at the bottom of the file:

override_dh_auto_test:

which essentially disables dh_auto_test by replacing it with an empty set of commands. The reason for this becomes clear when we take a look at the test target of the upstream Makefile and the dependencies it has: tap, a node.js library that is not yet available in Debian. In other words, we can't run the test suite on the build machines so we need to disable it here.

debian/compat

9

This file simply specifies the version of debhelper that is required by the various helpers used in debian/rules. Version 9 is the latest at the moment.

debian/copyright

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: node-libravatar
Upstream-Contact: Francois Marier <francois@libravatar.org>
Source: https://github.com/fmarier/node-libravatar
Files: *
Copyright: 2011 Francois Marier <francois@libravatar.org>
License: Expat
Files: debian/*
Copyright: 2012 Francois Marier <francois@debian.org>
License: Expat
License: Expat
 Permission is hereby granted, free of charge, to any person obtaining a copy of this
 software and associated documentation files (the "Software"), to deal in the Software
 without restriction, including without limitation the rights to use, copy, modify,
 merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
 permit persons to whom the Software is furnished to do so, subject to the following
 conditions:
 .
 The above copyright notice and this permission notice shall be included in all copies
 or substantial portions of the Software.
 .
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
 PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
 CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
 OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

This machine-readable file lists all of the different licenses encountered in this package. It requires that the maintainer audits the upstream code for any copyright statements that might be present in addition to the license of the package as a whole.

debian/docs

README.md

This file contains a list of upstream files that will be copied into the /usr/share/doc/node-libravatar/ directory by dh_installdocs.

debian/node-libravatar.install

lib/*    usr/lib/nodejs/

The install file is used by dh_install to supplement the work done by dh_auto_install which, as we have seen earlier, essentially just runs make install on the upstream Makefile. Looking at that upstream Makefile, it becomes clear that the files will need to be installed manually by the Debian package since that Makefile doesn't have an install target.

debian/watch

version=3
https://github.com/fmarier/node-libravatar/tags /fmarier/node-libravatar/archive/node-libravatar-([0-9.]+)\.tar\.gz

This is the file that allows Debian tools like the Package Tracking System to automatically detect that a new upstream version is available. What it does is simply visit the upstream page which contains all of the release tarballs and look for links which have an href matching the above regular expression. Running uscan --report --verbose will show us all of the tarballs that can be automatically discovered using this watch file:

-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
   https://github.com/fmarier/node-libravatar/tags /fmarier/node-libravatar/archive/node-libravatar-([0-9.]+)\.tar\.gz
-- Found the following matching hrefs:
     /fmarier/node-libravatar/archive/node-libravatar-2.0.0.tar.gz
     /fmarier/node-libravatar/archive/node-libravatar-1.1.1.tar.gz
     /fmarier/node-libravatar/archive/node-libravatar-1.1.0.tar.gz
     /fmarier/node-libravatar/archive/node-libravatar-1.0.1.tar.gz
     /fmarier/node-libravatar/archive/node-libravatar-1.0.0.tar.gz
Newest version on remote site is 2.0.0, local version is 2.0.0
 => Package is up to date
-- Scan finished

pylibravatar This second package is the equivalent Python library for the Libravatar service. Version 1.6-2 of that package contains similar files in its debian/ directory, but let's look at two in particular:

• control
• upstream/signing-key.asc

debian/control

Source: pylibravatar
Section: python
Priority: optional
Maintainer: Francois Marier <francois@debian.org>
Build-Depends: debhelper (>= 9), python-all, python3-all
Standards-Version: 3.9.5
Homepage: https://launchpad.net/pyLibravatar
...
Package: python-libravatar
Architecture: all
Depends: $ misc:Depends , $ python:Depends , python-dns, python
Description: Libravatar module for Python 2
 Module to make use of the federated Libravatar.org avatar hosting service
 from within Python applications.
...
Package: python3-libravatar
Architecture: all
Depends: $ misc:Depends , $ python3:Depends , python3-dns, python3
Description: Libravatar module for Python 3
 Module to make use of the federated Libravatar.org avatar hosting service
 from within Python applications.
...

Here is an example of a source package (pylibravatar) which builds two separate binary packages: python-libravatar and python3-libravatar. This highlights the fact that a given upstream source can be split into several binary packages in the archive when it makes sense. In this case, there is no point in Python 2 applications pulling in the Python 3 files, so the two separate packages make sense. Another common example is the use of a -doc package to separate the documentation from the rest of a package so that it doesn't need to be installed on production servers for example.

debian/upstream/signing-key.asc

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1
mQINBEpQYz4BEAC7REQD1za69RUnkt6nRCFhSJmmoeJc+yEiWTKc9GOIMAwJDme1
+CMYgVn4Xzf1VQYwD/lE+mfWgyeMomLQjDM1mxx/LOM2a1WWPOk9+PvQwKfRJy92
...
UxDtZm/4yUmU6KvHvOGiDCMuIiB+MqhqJJ5wf80wXhzu8nmC+fyGt6nvu0ggMle8
sAMgXt/aQUTZE5zNCQ==
=RkTO
-----END PGP PUBLIC KEY BLOCK-----

This is simply the OpenPGP key that the upstream developer uses to sign release tarballs. Since PGP signatures are available on the upstream download page, it's possible to instruct uscan to check signatures before downloading tarballs. The way to do that is to use the pgpsigurlmange option in debian/watch:

version=3
opts=pgpsigurlmangle=s/$/.asc/ https://pypi.python.org/pypi/pyLibravatar https://pypi.python.org/packages/source/p/pyLibravatar/pyLibravatar-(.*)\.tar\.gz

which is simply a regular expression replacement string which takes the tarball URL and converts it to the URL of the matching PGP signature.

fcheck The last package we will look at is a file integrity checker. It essentially goes through all of the files in /usr/bin/ and /usr/lib/ and stores a hash of them in its database. When one of these files changes, you get an email. In particular, we will look at the following files in the debian/ directory of version 2.7.59-18:

• dirs
• fcheck.cron.d
• fcheck.postrm
• fcheck.postinst
• patches/
• README.Debian
• rules
• source/format

debian/patches This directory contains ten patches as well as a file called series which lists the patches that should be applied to the upstream source and in which order. Should you need to temporarily disable a patch, simply remove it from this file and it will no longer be applied at build time. Let's have a look at patches/04_cfg_sha256.patch:

Description: Switch to sha256 hash algorithm
Forwarded: not needed
Author: Francois Marier <francois@debian.org>
Last-Update: 2009-03-15
--- a/fcheck.cfg
+++ b/fcheck.cfg
@@ -149,8 +149,7 @@ TimeZone        = EST5EDT
 #$Signature      = /usr/bin/sum
 #$Signature      = /usr/bin/cksum
 #$Signature      = /usr/bin/md5sum
-$Signature      = /bin/cksum
-
+$Signature      = /usr/bin/sha256sum
 # Include an optional configuration file.

This is a very simple patch which changes the default configuration of fcheck to promote the use of a stronger hash function. At the top of the file is a bunch of metadata in the DEP-3 format. Why does this package contain so many customizations to the upstream code when Debian's policy is to push fixes upstream and work towards reduce the delta between upstream and Debian's code? The answer can be found in debian/control:

Homepage: http://web.archive.org/web/20050415074059/www.geocities.com/fcheck2000/

This package no longer has an upstream maintainer and its original source is gone. In other words, the Debian package is where all of the new bug fixes get done.

debian/source/format

3.0 (quilt)

This file contains what is called the source package format. What it basically says is that the patches found in debian/patches/ will be applied to the upstream source using the quilt tool at build time.

debian/fcheck.postrm

#!/bin/sh
# postrm script for fcheck
#
# see: dh_installdeb(1)
set -e
# summary of how this script can be called:
#        * <postrm>  remove'
#        * <postrm>  purge'
#        * <old-postrm>  upgrade' <new-version>
#        * <new-postrm>  failed-upgrade' <old-version>
#        * <new-postrm>  abort-install'
#        * <new-postrm>  abort-install' <old-version>
#        * <new-postrm>  abort-upgrade' <old-version>
#        * <disappearer's-postrm>  disappear' <overwriter>
#          <overwriter-version>
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package
case "$1" in
    remove upgrade failed-upgrade abort-install abort-upgrade disappear)
    ;;
    purge)
      if [ -e /var/lib/fcheck/fcheck.dbf ]; then
        echo "Purging old database file ..."
        rm -f /var/lib/fcheck/fcheck.dbf
      fi
      rm -rf /var/lib/fcheck
      rm -rf /var/log/fcheck
      rm -rf /etc/fcheck
    ;;
    *)
        echo "postrm called with unknown argument \ $1'" >&2
        exit 1
    ;;
esac
# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.
#DEBHELPER#
exit 0

This script is one of the many possible maintainer scripts that a package can provide if needed. This particular one, as the name suggests, will be run after the package is removed (apt-get remove fcheck) or purged (apt-get remove --purge fcheck). Looking at the case statement above, it doesn't do anything extra in the remove case, but it deletes a few files and directories when called with the purge argument.

debian/README.Debian This optional README file contains Debian-specific instructions that might be useful to users. It supplements the upstream README which is often more generic and cannot assume a particular system configuration.

debian/rules

#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
build-arch:
build-indep:
build: build-stamp
build-stamp:
    dh_testdir
    pod2man --section=8 $(CURDIR)/debian/fcheck.pod > $(CURDIR)/fcheck.8
    touch build-stamp
clean:
    dh_testdir
    dh_testroot
    rm -f build-stamp 
    rm -f $(CURDIR)/fcheck.8
    dh_clean
install: build
    dh_testdir
    dh_testroot
    dh_prep
    dh_installdirs
    cp $(CURDIR)/fcheck $(CURDIR)/debian/fcheck/usr/sbin/fcheck
    cp $(CURDIR)/fcheck.cfg $(CURDIR)/debian/fcheck/etc/fcheck/fcheck.cfg
# Build architecture-independent files here.
binary-arch: build install
# Build architecture-independent files here.
binary-indep: build install
    dh_testdir
    dh_testroot
    dh_installdocs
    dh_installcron
    dh_installman fcheck.8
    dh_installchangelogs
    dh_installexamples
    dh_installlogcheck
    dh_link
    dh_strip
    dh_compress
    dh_fixperms
    dh_installdeb
    dh_shlibdeps
    dh_gencontrol
    dh_md5sums
    dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install

This is an example of a old-style debian/rules file which you still encounter in packages which haven't yet upgraded to the latest version of debhelper 9, as can be shown by the contents of debian/compat:

8

It does essentially the same thing that what we've seen in the build log, but in a more verbose way.

debian/dirs

usr/sbin
etc/fcheck

This file contains a list of directories that dh_installdirs will create in the build directory. The reason why these directories need to be created is that files are copied into these directories in the install target of the debian/rules file. Note that this is different from directories which are created at the time of installation of the package. In that case, the directory (e.g. /var/log/fcheck/) must be created in the postinst script and removed in the postrm script.

debian/fcheck.cron.d

#
# Regular cron job for the fcheck package
#
30 */2  * * *   root    test -x /usr/sbin/fcheck && if ! nice ionice -c3 /usr/sbin/fcheck -asxrf /etc/fcheck/fcheck.cfg >/var/run/fcheck.out 2>&1; then mailx -s "ALERT: [fcheck]  hostname --fqdn " root </var/run/fcheck.out ; /usr/sbin/fcheck -cadsxlf /etc/fcheck/fcheck.cfg ; fi ; rm -f /var/run/fcheck.out

This file is the cronjob which drives the checks performed by this package. It will be copied to /etc/cron.d/fcheck by dh_installcron.

It took some time, but now it s finally done: KDE has translations for AppStream upstream metadata! AppStream is a Freedesktop project to extend metadata about the software projects which is available in distributions, especially regarding applications. Distributions compile a metadata file from data collected from packages, .desktop files and possibly other information sources, and create an AppStream XML file from it, which is then directly or via a Xapian cache read by software-center-like applications such as GNOME-Software or KDEs Apper. Since the metadata available from current sources is not standardized and rather poor, upstream projects can ship small XML files, AppStream upstream metadata or AppData in short. These files contain additional information about a project, such as a long description and links to screenshots. They also provide hints about public interfaces a software provides, for example binaries and libraries, making it possible for distributors to give users exactly the right package name in case they are missing a software component. So, in order to represent graphical KDE applications like they deserve it in the new software centers making use of AppStream, we need to ship AppData files, with long descriptions, screenshots and a few URLs. But how can you create these metadata files? In case you want your graphical KDE app to ship an AppData file, there is now a help page on the Techbase Wiki which provides all information needed to get started! For non-visual stuff or software which just wants to publish it s provided interfaces with AppStream metadata, there is a dedicated page for that as well. Shipping metadata for non-GUI apps will help programmers to satisfy depedencies in order to compile new software, enhance bash-completion for missing binaries and provides some other neat stuff (take a look at this blogpost to get a taste of it). And if you want to read a FAQ about the metadata stuff and get the bigger picture, just go to the Techbase Wiki page about AppStream metadata as well. The pages are not 100% final, so if you have questions, please write me a mail and I ll update the pages, or simply correct/refine it by yourself (it s a wiki afterall). And now to the best thing: As soon as you ship an AppStream upstream metadata file (*.appdata.xml* for apps or *.metainfo.xml* for other stuff), the KDE l10n-script (Scripty!) will automatically start translating it, just like we already do with .desktop files. No further actions are necessary. I already have a large amount of metadata files here, partially auto-generated, which show that we have about 160+ applications in KDE which could get an AppData file, not counting any frameworks or other non-GUI stuff yet. Since that is a bit much to submit via Reviewboard (which I originally planned to do), I hope I can commit the changes directly to the respective repositories, where the maintainers can take a look at it and adjust it to their liking. If that idea does not receive approval, I will just publish a set of data at some place for the KDE app maintainers to take as a reference (the auto-generated stuff needs some fixup to be commit-ready (which I d do in case I can just commit changes)). Either way, it is safe now to write and ship AppData files in KDE projects! In order to get your stuff translated, it is necessary that you follow the AppStream 0.6 metadata specification, and not one of ther older revisions. You can easily detect 0.6 metadata by the <component> root node, instead of <application>, or by it having a metadata_license tag. We don t support the older versions simply because it s not necessary, as there were only two KDE projects shipping AppData before, which are now using 0.6 data as well. Since 0.6, the metadata XML format is guaranteed to be stable, and the only reason which could make me change it in an incompatible way is to prevent something as bad as the end of the world from happening (== won t happen ). You can find the full specification (upstream and distro data) here. All parsers are able to handle 0.6 data now, and the existing tools are almost all migrated already (might take a few months to hit the distributions though). So, happy metadata-writing! Thanks to all people who helped with making this happen, and especially Burkhard L ck and Albert Astals Cid for their patch-review and help with integrating the necessary changes into the KDE l10n-script.

The GNOME and many other infrastructures have been recently attacked by an huge amount of subscription-based spam against their Mailman istances. What the attackers were doing was simply launching a GET call against a specific REST API URL passing all the parameters it needed for a subscription request (and confirmation) to be sent out. Understanding it becomes very easy when you look at the following example taken from our apache.log:

May 3 04:14:38 restaurant apache: 81.17.17.90, 127.0.0.1 - - [03/May/2014:04:14:38 +0000] "GET /mailman/subscribe/banshee-list?email=example@me.com&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 403 313 "http://spam/index2.html" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36"

As you can the see attackers were sending all the relevant details needed for the subscription to go forward (and specifically the full name, the email, the digest option and the password for the target list). At first we tried to either stop the spam by banning the subnets where the requests were coming from, then when it was obvious that more subnets were being used and manual intervention was needed we tried banning their User-Agents. Again no luck, the spammers were smart enough to change it every now and then making it to match an existing browser User-Agent. (with a good percentage to have a lot of false-positives) Now you might be wondering why such an attack caused a lot of issues and pain, well, the attackers made use of addresses found around the web for their malicius subscription requests. That means we received a lot of emails from people that have never heard about the GNOME mailing lists but received around 10k subscription requests that were seemingly being sent by themselves. It was obvious we needed to look at a backup solution and luckily someone on our support channel suggested the freedesktop.org sysadmins recently added CAPTCHAs support to Mailman. I m now sharing the patch and providing a few more details on how to properly set it up on either DEB or RPM based distributions. Credits for the patch should be given to Debian Developer Tollef Fog Heen, who has been so kind to share it with us. Before patching your installation make sure to install the python-recaptcha package (tested on Debian with Mailman 2.1.15) on DEB based distributions and python-recaptcha-client on RPM based distributions. (I personally tested it against Mailman release 2.1.15, RHEL 6) The Patch

diff --git a/Mailman/Cgi/listinfo.py b/Mailman/Cgi/listinfo.py
index 4a54517..d6417ca 100644
--- a/Mailman/Cgi/listinfo.py
+++ b/Mailman/Cgi/listinfo.py
@@ -22,6 +22,7 @@
 
 import os
 import cgi
+import sys
 
 from Mailman import mm_cfg
 from Mailman import Utils
@@ -30,6 +31,8 @@ from Mailman import Errors
 from Mailman import i18n
 from Mailman.htmlformat import *
 from Mailman.Logging.Syslog import syslog
+sys.path.append("/usr/share/pyshared")
+from recaptcha.client import captcha
 
 # Set up i18n
 _ = i18n._
@@ -200,6 +203,9 @@ def list_listinfo(mlist, lang):
     replacements[''] = mlist.FormatFormStart('listinfo')
     replacements[''] = mlist.FormatBox('fullname', size=30)
 
+    # Captcha
+    replacements[''] = captcha.displayhtml(mm_cfg.RECAPTCHA_PUBLIC_KEY, use_ssl=False)
+
     # Do the expansion.
     doc.AddItem(mlist.ParseTags('listinfo.html', replacements, lang))
     print doc.Format()
diff --git a/Mailman/Cgi/subscribe.py b/Mailman/Cgi/subscribe.py
index 7b0b0e4..c1c7b8c 100644
--- a/Mailman/Cgi/subscribe.py
+++ b/Mailman/Cgi/subscribe.py
@@ -21,6 +21,8 @@ import sys
 import os
 import cgi
 import signal
+sys.path.append("/usr/share/pyshared")
+from recaptcha.client import captcha
 
 from Mailman import mm_cfg
 from Mailman import Utils
@@ -132,6 +130,17 @@ def process_form(mlist, doc, cgidata, lang):
     remote = os.environ.get('REMOTE_HOST',
                             os.environ.get('REMOTE_ADDR',
                                            'unidentified origin'))
+
+    # recaptcha
+    captcha_response = captcha.submit(
+        cgidata.getvalue('recaptcha_challenge_field', ""),
+        cgidata.getvalue('recaptcha_response_field', ""),
+        mm_cfg.RECPTCHA_PRIVATE_KEY,
+        remote,
+        )
+    if not captcha_response.is_valid:
+        results.append(_('Invalid captcha'))
+
     # Was an attempt made to subscribe the list to itself?
     if email == mlist.GetListEmail():
         syslog('mischief', 'Attempt to self subscribe %s: %s', email, remote)

Additional setup Then on the /var/lib/mailman/templates/en/listinfo.html template (right below <mm-digest-question-end>) add:

      <tr>
        <td>Please fill out the following captcha</td>
        <td><mm-recaptcha-javascript></TD>
      </tr>

Make also sure to generate a public and private key at https://www.google.com/recaptcha and add the following paramaters on your mm_cfg.py file:

• RECAPTCHA_PRIVATE_KEY
• RECAPTCHA_PUBLIC_KEY

Loading reCAPTCHAs images from a trusted HTTPS source can be done by changing the following line:

replacements[''] = captcha.displayhtml(mm_cfg.RECAPTCHA_PUBLIC_KEY, use_ssl=False)

to

replacements[''] = captcha.displayhtml(mm_cfg.RECAPTCHA_PUBLIC_KEY, use_ssl=True)

EPEL 6 related details A few additional details should be provided in case you are setting this up against a RHEL 6 host: (or any other machine using the EPEL 6 package python-recaptcha-client-1.0.5-3.1.el6) Importing the recaptcha.client module will fail for some strange reason, importing it correctly can be done this way:

ln -s /usr/lib/python2.6/site-packages/recaptcha/client /usr/lib/mailman/pythonlib/recaptcha

and then fix the imports also making sure sys.path.append( /usr/share/pyshared ) is not there:

from recaptcha import captcha

That s not all, the package still won t work as expected given the API_SSL_SERVER, API_SERVER and VERIFY_SERVER variables on captcha.py are outdated (filed as bug #1093855), substitute them with the following ones:

API_SSL_SERVER="https://www.google.com/recaptcha/api"
API_SERVER="http://www.google.com/recaptcha/api"
VERIFY_SERVER="www.google.com"

And then on line 76:

url = "https://%s/recaptcha/api/verify" % VERIFY_SERVER,

That should be all! Enjoy!

British taxpayers are paying for extra support for Windows XP due to a lack of planning by the UK government [1]. While the cost of this is trivial compared to other government stupidity (such as starting wars of aggression) this sort of thing should be stopped. The best way to solve such problems is for governments to only use free software. If the UK government used Red Hat Enterprise Linux then when Red Hat dropped support for old versions they would have the option of providing their own support for old versions, hiring any other company to support old versions, or paying Red Hat for supporting it. In that case the Red Hat offer would probably be quite reasonable as competition drives the prices down. It doesn t seem likely that the UK government will start using only free software in the near future. It s not impossible to do so, there are organisations dedicated to this task such as Free-gov.org which aims to develop e-government software that is under GPL licenses [2]. The Wikipedia page List of Linux Adopters [3] has a large section on government use, while not all entries are positive (some have reverted) it shows that it s possible to use Linux for all areas of government. But governments often move slowly and in the case of wealthy countries such as the UK it can be easier to just tax the citizens a little more than to go to the effort of saving money. But when governments use proprietary software they shouldn t be restricted in support. It seems that the only way to ensure that the government can do what it needs is to have a source escrow system. Then if the company that owned the software ceased supporting it anyone who wanted to offer support would be able to do so. This would probably require that software which is out of support be released to the public domain so that anyone who wanted to tender for such support work could first inspect the code to determine if they were capable of doing the work. People who believe the myths about secret source software claim that allowing the source code to be released would damage the company that owns it. This has been proved incorrect by the occasions when source code for software such as MS-Windows has been released on the Internet with no apparent harm. Also Microsoft have a long history of licensing their source code to universities, governments, and other companies for various purposes (including porting Windows to other CPUs). It s most likely that some part of the UK government already has the full source code to Windows XP, and it s also quite likely that computer criminals have obtained copies of the source by now for the purpose of exploiting security flaws. Also they stop supporting software when they can t make money from providing the usual support, so by definition the value to a company of the copyright is approaching zero by the time they decide to cease support. Given the lack of success experienced by companies that specialise in security (for example the attack on RSA to steal the SecurID data [4]) it doesn t seem plausible that Microsoft has had much success in keeping the source to Windows XP (or any other widely used product) secret over the course of 12 years. In summary source code to major proprietary software products is probably available to criminals long before support expires and is of little value to the copyright owners. But access to it can provide value to governments and other users of the software. The only possible down-side to the software vendor is if the new version doesn t provide any benefits to the user. This could be a problem for Microsoft who seem to have the users hate every second version of Windows enough to pay extra for the old version. The solution is to just develop quality software that satisfies the needs of the users. Providing a legal incentive for this would be a good idea.

• [1] http://grahamcluley.com/2014/04/windows-xp-security-updates-cost/
• [2] http://free-gov.org/
• [3] https://en.wikipedia.org/wiki/List_of_Linux_adopters
• [4] http://www.cybersquared.com/2011/03/rsa-compromised-by-apt/

okay. New hypervisor hardware. Switching from xen to KVM. I took a snapshot of the xen partitions and moved them to a holding location during migration. I am now imaging these partitions to the LVM block devices:

calcifer:/home/cjac# for guest in  ls /usr/src/moonunit-guests/   grep -v -e etc   awk -F- ' print $1 '  ; do lvcreate /dev/vg00 -n $ guest  -L 4200M -C y ; done
  Logical volume "edge" created
  Logical volume "ns0" created
  Logical volume "sh1" created
  Logical volume "sip0" created
  Logical volume "smtp" created
  Logical volume "vpn1" created
  Logical volume "wsg" created
calcifer:/home/cjac# partprobe /dev/vg00/edge
calcifer:/home/cjac# fdisk -l /dev/vg00/edge
GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
Disk /dev/dm-21: 4 GB, 4400524800 bytes
255 heads, 63 sectors/track, 535 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
     Device Boot      Start         End      Blocks   Id  System 
/dev/dm-21p1               1         535     4297356   83  Linux
calcifer:/home/cjac# kpartx -l /dev/vg00/edge
vg00-edge1 : 0 8594712 /dev/vg00/edge 63
calcifer:/home/cjac# kpartx -a /dev/vg00/edge
calcifer:/home/cjac# dd if=/usr/src/moonunit-guests/edge-disk-20140420T070034.xz   xz -d   dd of=/dev/mapper/vg00-edge1 
503474+1 records in
503474+1 records out
257778704 bytes (258 MB) copied, 311.538 s, 827 kB/s
8388608+0 records in
8388608+0 records out
4294967296 bytes (4.3 GB) copied, 925.612 s, 4.6 MB/s
calcifer:/home/cjac# mount /dev/mapper/vg00-edge1 /mnt/tmp
calcifer:/home/cjac# cp -r /lib/modules/ uname -r  /mnt/tmp/lib/modules/
calcifer:/home/cjac# emacs /mnt/tmp/etc/inittab
calcifer:/home/cjac# emacs /mnt/tmp/etc/fstab
calcifer:/home/cjac# umount /mnt/tmp
calcifer:/home/cjac# kpartx -d /dev/vg00/edge
calcifer:/home/cjac# virsh start edge && virsh console edge

Somebody needs faster drives. Wow was that ever slow.

url_for is normally used to avoid hard coding of URL in Flask based webapps. I've been using it in SILPA port written using Flask by. But this was written long back and written as POC to show for Santhosh author of SILPA app which even managed to go into production :-). Recently I started organizing the code and started using flask.Blueprint which was previously written using flask.views.MethodView class and here I started facing problem with old templates. I'm just gonna explain what is the difference when using url_for with MethodView and Blueprint. Lets have some sample code for MethodView first, this code is from Flask documentation. Here we have a view which is derived from MethodView which has logic on how to handle the requests. We use add_url_rule to register rule to handle /users/ url end point and we pass the class as view function which is done by as_view class method and we can refer this method in our Jinja2 templates using name users. So a statement like in our templates will be converted to /users/ URL when page is rendered to client by Flask. Now when I replaced the MethodView in favor of Blueprint I started getting up werkzeug.routing.BuildError thrown on my face and I had no clue why!. Yeah I know I'm bad at reading documentation but even after reading documentation I was still thinking that should return me a proper URL and I was wondering why its failing. Finally after re-reading documentation for url_for it was becoming clear to me, url_for definition looks like below Here endpoint is actually a function which is supposed to be serving the URL and **values is the arguments for this function. The URL in question should be defined in python code using decorator. In my case following is the new function serving the web pages for SILPA. You can ignore function code but just note the decorators, here I'm registering the function serve_pages with page as argument for URL patterns / and /<page>, _BASE_URL here is mount point of application it can be just / or /mountpoint depending on that URL registered changes. Now I need to modify code for all url_for in my template to look like below The . in front of function is for referring current Blueprint, in my case the Flask will consider it as frontend.serve_pages as function name and generates appropriate URL at run time. So my fault was misunderstanding endpoint argument as URL endpoint but where as its actually function name supposed to serve the page. But when using MethodViews I can simply convert class to a function with my preferred name just like UserAPI.as_view('/') so url_for('/') just works.

I've been asked to make another design proposal for the Minidebconf. People have been brainstorming. I could have asked them to do that months ago. I didn't, because I was working with my own ideas. We need to know who and what we are aiming at with the graphic communication, as well as with the conference. Who is the design for? What should they do? Why? Who is the conference for? Who should be interested? Is the design for people in Barcelona only? Is it for women only? Is it for current developers? Or is it for local politicians? Male or female? Students? - only? Does the communication have other goals than getting people at the venue? Should the design reflect the organizers - or rather not? Does the geography have to play a role in the visual imagery? These are questions that should always be asked. I made the mistake to answer a lot of the questions myself, based on my second hand knowledge and guesses. A common mistake, I've made before and will probably make again. I'm used to working on my own, that's my poor excuse. To my mind, the gathering, the meeting in the flesh and the communication and sharing of knowledge, is far more important than local landmarks. I don't feel that strongly for a location oriented identity design. La Sagrada Familia doesn't have anything to do with a gathering for free software development, does it. How? Oh, that was the minidebconf in Barcelona
Oh, that was the minidebconf arranged by Debian Women
Oh, that was the minidebconf that made a point out of being inclusive
Oh, that was the minidebconf that The identity design might have more to do with support to the local group than with any of the other aspects of the conference. Interesting. This table of colors shows different ways a blue and a purple could go. I put the green colors there to have more options covered for the discussion today. You can see how the different hues interacts with the red of the logo. The colors can be referred to like this: B3, C6, A4 etc. Click on the image for full size version. Here is an idea based on all the purple colors. Fun, uplifting, feels like many voices. Too many colors for T-shirt print, maybe: Here is some ideas of how to implement a minimalistic solution that I recommend for minidebconfs: My suggestion is that the banner (and everything else displaying the event) has the logo of the organizers placed on it. The font used for headlines etc is semantically of another nature than the logo, though it could be the same. I prefer neutral fonts, that can be reused by the next minidebconf, and I suggest a sans serif font. A condensed font makes huge display easier to fit. Don't be confused by displayfonts, I aim to show you that type alone speaks loudly, and if this typography should be recycled, we should not choose one of them, but go with the "neutral" sans serif. I need suggestions of free and good sans serif fonts.

My proposal for visual design for the MiniDebConf has been received well. People seem to like the general idea, which worried me the most. If people hated that idea, I'd have to go back and cook something up on Mir However, organizers in Spain do worry that the visual expression will be confused with that of a local political party. I see no danger of that. They use speech bubbles and orange. So does the telecompany Orange (if it still exists) - and Ubuntu. By the way, I see in this small size that my new choice of font for the speech bubbles is too weak. It needs more work. It's been suggested I try out a brighter orange. The color in the middle is my original choice, the one at the top is fine, but you can almost tell no difference, when they are not placed closely together. The same danger of confusion will (not) be there with any orange from "curry" to "crocus". I show the color in the bottom because it makes it evident how narrow the gap between these colors is - there is very tight room for adjustments. Yellow is too bright and cheap looking, like a discount sign color. I've looked into other colors, but so far I've not found any good replacement, since I no longer have any gut feeling to hang my hat on, except for the Debian logo color - they have to be a good match. I know I'm free to do whatever, Jonas just reminded me, but of all the colors in the World, thinking of Spain, I only feel orange. Not blue, not green, not purple. Red is already used. Yellow looks cheap. A dusty palette is not uplifting I could choose a pink, and that would actually be fun. But pink is not serious. Pink can't be taken seriously. Like women can't? OK, now it's gotta be pink! Well, I'm not really serious now. The serious thing to do for me now will be to watch some Spanish movies to get a new gut feeling about Spain. A dosis of Almod var would be suitable. Alternatively I must chat with some Spanish friends. But maybe, just maybe, the Barcelona organizers will be just as happy with the new orange color as I am. Life can sometimes be that easy.

Since the MiniDebConf Jonas and I have been travelling in Spain, France and finally staying in Belgium for a week, getting some work done. It's been harder than imagined to work during travel. I haven't exercised either, and regained at least three of four kilos I spent much time and effort getting rid in the year preceding. I thrive in my home and find it hard to keep my own time and focus when I am deprived of my own space. It was challenging to give a talk, "Why aren't more designers using Debian or working for Debian", my first public talk. I've been working to recapture my points in writing, to make a stronger statement, but I seem to blur my own views with conflicting ones, and I'm loosing momentum every day. One of my reasons for speaking up was to do it even though I'm not at trained speaker and have "nothing" to contribute but my opinions from the angle of a user that happens to be a designer. Not claiming to be a superior designer, but one that would like to contribute if it was easier to figure out how. And since the community wants to encourage designers to contribute to the Debian project, I figured it to be a good idea to talk about how this has been challenging to me as a dedicated user and completely out of the question for any other designer I know - or knew before the minidebconf. No reseach, no scientific proofs, just my wiew from my "dumb user" and designer's perspective. I saw one single attendant rolling his eyes during my talk. I didn't care at that time, but I've given that look more consideration than the people approaching me after the talk, saying thank you for voicing their opinions and thoughts. I think that's absolutely astonishing and at the same time it's just typically me. It makes me angry, first with myself for not speaking to this man's perception of things, then with myself for not just letting go of that image. I'm really glad that so many seemed to listen with curiosity and interest. What if one more - or half of the auditorium - had rolled their eyes? I don't like to feel that vulnerable. The truth is, though, that I'm really not. I gave the talk against my fear of failure and public humiliation and I'm convinced that my thoughts and actions matter, just as anybody's does, if we dare to say what's on our minds and to take action. I believe it's in anybody's power to "make a difference" and even "change the world" - at least in a small way. I guess that's one of the underlying reasons to be a designer in the first place. That is quite a strong position to take. I've created the wikipage http://wiki.debian.org/Design - well knowing that design is a word with many meanings. Everything is design. Since the talk I've been in doubt about that page. About the project, my aim with it, what to do about it, how to move on with just a tiny babystep, and I realise that I'm simply afraid to be disturbing someone's peace, making people angry or roll their eyes at my fumbling attempts to figure out in public what can be done to make a thriving community of designers collaborating with coders to make better, more usable and attractive software in the free, wide world. I'm starting a design process, not presenting a perfect, finished solution. Now, having put these thoughts into words, perhaps, my mind will be somewhat appeaced and let me move on with my intended tasks of cultivating that acclaimed space in the Debian information jungle into a friendly and welcoming place with info that makes it easier to be a contributing designer in Debian.

Me: Goodnight, Jacob. I love you, and I always will. Jacob: *happy sigh* Goodnight dad. I love you too. But dad, will you love us if you go on a trip? Me: Of course! Even when Jacob, interrupting, and serious: Dad, you should not take a train trip without me. Me: Jacob, I promise that I will take you on more train trips. Jacob: And Oliver! Me: Oh yes! I promise I will take you and Oliver on more train trips. Jacob: Another happy sigh, and a big smile. Dad, you have to remember your promise forever, OK? Me: Yes, Jacob, I will remember that promise forever. Good night. (written January 19, 2013, but somehow forgot to click publish back then.)

The seventh Debian Groupware Meeting was held in the LinuxHotel, Essen, Germany. We had one remote hacker from NYC which brings the number of attendants up to 9. This is a short summary of what happened during the weekend:

• We decided to abandon Iceowl (based on the standalone calendar sunbird) since Mozilla started to actively remove the code. Unfortunately this leaves us without a proper GUI stand alone calendar client with GSSAPI support.
• The icedove package got a major cleanup including the switch from CDBS to dh and the removal of the rebranding logic. This will hopefully allow us to better keep in sync with upstream. Carsten's git repo usually carries the most up to date version and a automated build of these version is in the works.
• The sogo connector extension for icedove got uploaded and tested including a wiki page
• The Groupware Page got updated
• We discussed the possibility of caldav/carddav servers in Debian using autopkgtest. This resulted in caldav-tester being packaged. It's currently waiting for an updated dependency before it can be uploaded.
• Based on that we added minimal autopkg tests to calypso. The later also gained GSSAPI support.
• OpenChange got updated in experimental (now moved to sid) and got a debug package. There were also some upstream improvements to ease provisioning.
• Dovecot's installation of the Sieve ext_programs was fixed
• SOPE and SOGo got updated to the latest upstream versions
• The SOGo-OpenChange plugin got build against the OpenChange package in experimental
• Giraffe (aka Zarafa packaging) made nice progress including the switch to free artwork and further renaming of the services. For Details on the current state check the wiki page.
• Due to the warm spring we had two nice barbecues for lunch.

Since we had a nice mix of first time Debian contributors, Debian Maintainers and Debian Developers we had lots of room for discussion and co-working which made this an exciting weekend.

I have heard many good things about Docker, and decided to give it a spin on my systems. I think application-level virtualization has a lot to offer to my workflow... But the process to understand and later adopt it has left me somewhat heart-torn. Docker is clearly great technology, but its documentation is... Condescending and completely out of line with what I have grown used to in my years using Linux. First, there is so much simplistic self-praise sprinkled throughout it. There is almost no page I landed on that does not mention how user-friendly and user-centric Docker's commandline arguments are They let you talk in almost plain1 English. What they don't mention is that... Well, that's the way of basically every command-line tool. Of course, as soon as you start specifying details to it, the plain-Englishness starts dilluting into a more realistic English-inspiredness... Then... Things that go against our historical culture. It is often said that Windows documentation tends to be repetitive because users don't have the patience to read a full document. And our man pages are succint and to the point, because in our culture it is expected that users know how to search for the bit of information they are after. But reading documentation that's so excited with itself and praises again and again the same values and virtues, but never gets to the point I am interested in getting at (be it deployment, interoperation, description of the in-disk images+overlays layout, or anything moderately technical) never gets there... makes me quite unhappy. Last (for now)... Such a continuous sales pitch, an insistence on the good virtues, makes me wary of something they might be hiding. Anyway, at least for now, I just wanted to play a bit with it; I will wait at least until there is a backport to the stable Debian version before I consider moving my LXC VMs setup over to Docker (and a backport does not seem trivial to achieve, as Docker has several updated low-level dependencies we are unlikely to see in Wheezy). But I had to vent this. OK, now go back to your regular work ;-)

• 1. Of course, plain as long as you agree to a formal grammar... Details, details

I've been following the Gnash project for quite a while now. It is a free software implementation of Adobe Flash, both a standalone player and a browser plugin. Gnash implement support for the AVM1 format (and not the newer AVM2 format - see Lightspark for that one), allowing several flash based sites to work. Thanks to the friendly developers at Youtube, it also work with Youtube videos, because the Javascript code at Youtube detect Gnash and serve a AVM1 player to those users. :) Would be great if someone found time to implement AVM2 support, but it has not happened yet. If you install both Lightspark and Gnash, Lightspark will invoke Gnash if it find a AVM1 flash file, so you can get both handled as free software. Unfortunately, Lightspark so far only implement a small subset of AVM2, and many sites do not work yet. A few months ago, I started looking at Coverity, the static source checker used to find heaps and heaps of bugs in free software (thanks to the donation of a scanning service to free software projects by the company developing this non-free code checker), and Gnash was one of the projects I decided to check out. Coverity is able to find lock errors, memory errors, dead code and more. A few days ago they even extended it to also be able to find the heartbleed bug in OpenSSL. There are heaps of checks being done on the instrumented code, and the amount of bogus warnings is quite low compared to the other static code checkers I have tested over the years. Since a few weeks ago, I've been working with the other Gnash developers squashing bugs discovered by Coverity. I was quite happy today when I checked the current status and saw that of the 777 issues detected so far, 374 are marked as fixed. This make me confident that the next Gnash release will be more stable and more dependable than the previous one. Most of the reported issues were and are in the test suite, but it also found a few in the rest of the code. If you want to help out, you find us on the gnash-dev mailing list and on the #gnash channel on irc.freenode.net IRC server.

Background I ve previously written about the claim that people use Autism as an excuse for bad behavior [1]. In summary it doesn t and such claims instead lead to people not being assessed for Autism. I ve also previously written about empathy and Autism in the context of discussions about conference sexual harassment [2]. The main point is that anyone who s going to blame empathy disorders for the widespread mistreatment of women in society and divert the subject from the actions of average men to men in minority groups isn t demonstrating empathy. Discussions of the actions of average men are so often derailed to cover Autism that the Geek Feminism Wiki has a page about the issue of blaming Autism [3]. The Latest Issue Last year Shanley Kane wrote an informative article for Medium titled What Can Men Do about the treatment of women in the IT industry [4]. It s a good article, I recommend reading it. As an aside @shanley s twitter feed is worth reading [5]. In response to Shanley s article Jeff Atwood wrote an article of the same title this year which covered lots of other things [6]. He writes about Autism but doesn t seem to realise that officially Asperger Syndrome is now Autism according to DSM-V (they decided that separate diagnosis of Autism, Asperger Syndrome, and PDD-NOS were too difficult and merged them). Asperger Syndrome is now a term that refers to historic issues (IE research that was published before DSM-V) and slang use. Gender and the Autism Spectrum Jeff claims that autism skews heavily towards males at a 4:1 ratio and cites the Epidemiology of Autism Wikipedia page as a reference. Firstly that page isn t a great reference, I fixed one major error (which was obviously wrong to anyone who knows anything about Autism and also contradicted the cited reference) in the first section while writing this post. The Wikipedia page cites a PDF about the Epidemiology of Autism that claims the 4.3:1 ratio of boys to girls [7]. However that PDF is a summary of other articles and the one which originated the 4.3:1 claim is behind a paywall. One thing that is worth noting in the PDF is that the section containing the 4.3:1 claim also references claims about correlations between race and Autism and studies contradicting such claims it notes the possibility of ascertainment bias . I think that anyone who reads that section should immediately consider the possibility of ascertainment bias in regard to the gender ratio. Most people who are diagnosed with Autism are diagnosed as children. An Autism diagnosis of a child is quite subjective, an important part is an IQ test (where the psychologist interprets the intent of the child in the many cases where answers aren t clear) to compare social skills with IQ. So whether a child is diagnosed is determined by the psychologist s impression of the child s IQ vs the impression of their social skills. Whether a child is even taken for assessment depends on whether they act in a way that s considered to be obviously different. Any child who is suspected of being on the Autism Spectrum will be compared other children who have been diagnosed (IE mostly boys) and this will probably increase the probability that a boy will be assessed. So an Aspie girl might not be assessed because she acts like other Aspie girls not like the Aspie boys her parents and teachers have seen. The way kids act is not solely determined by neuro-type. Our society expects and encourages boys to be louder than girls and take longer and more frequent turns to speak, this is so widespread that I don t think it s possible for parents to avoid it if their kids are exposed to the outside world. Because of this boys who would be diagnosed with Asperger Syndrome by DSM-IV tend to act in ways that are obviously different from other kids. While the combination of Autism and the the social expectations on girls tends to result in girls who are quiet, shy, and apologetic. The fact that girls are less obviously different and that their differences cause fewer difficulties for parents and teachers makes them less likely to be assessed. Note that the differences in behavior of boys and girls who have been diagnosed is noted by the professionals (and was discussed at a conference on AsperGirls that my wife attended) while the idea that this affects assessment rates is my theory. Jeff also cites the book The Essential Difference: Male And Female Brains And The Truth About Autism by Professor Simon Baron-Cohen (who s (in)famous for his Extreme Male Brain theory). The first thing to note about the Extreme Male Brain theory are that it depends almost entirely on the 4.3:1 ratio of males to females on the Autism Spectrum (which is dubious as I noted above). The only other evidence in support of it is subjective studies of children which suffer from the same cultural issues this is why double blind tests should be used whenever possible. The book Delusions of Gender by Cordelia Fine [8] debunks Simon Baron-Cohen s work among other things. The look inside feature of the Amazon page for Delusions of Gender allows you to read about Simon Baron-Cohen s work [9]. Now even if the Extreme Male Brain theory had any merit it would be a really bad idea to cite it (or a book based on it) if you want to make things better for women in the IT industry. Cordelia s book debunks the science and also shows how such claims about supposed essential difference are taken as exclusionary. The Problem with Jeff Atwood Jeff suggests in his post that men should listen to women. Then he and his followers have a huge flame-war with many women over twitter during which which he tweeted Trying to diversify my follows by following any female voices that engaged me in a civil, constructive way recently . If you only listen to women who agree with you then that doesn t really count as listening to women. When you have a stated policy of only listening to women who agree then it seems to be more about limiting what women may feel free to say around you. The Geek Feminism wiki page about the Tone Argument [10] says the following: One way in which the tone argument frequently manifests itself is as a call for civility. A way to gauge whether a request for civility is sincere or not is to ask whether the person asking for civility has more power along whatever axes are contextually relevant (see Intersectionality) than the person being called incivil , less power, or equal power. Often, people who have the privilege of being listened to and taken seriously level accusations of incivility as a silencing tactic, and label as incivil any speech or behavior that questions their privilege. For example, some men label any feminist thought or speech as hostile or impolite; there is no way for anybody to question male power or privilege without being called rude or aggressive. Likewise, some white people label any critical discussion of race, particularly when initiated by people of color, as incivil. Writing about one topic is also a really good idea. A blog post titled What Can Men Do should be about things that men can do. Not about Autism, speculation about supposed inherent differences between men and women which are based on bad research, gender diversity in various occupations, etc. Following up a post on What Can Men Do with discussion (in blog comments and twitter) about what women should do before they are allowed to join the conversation is ridiculous. Jeff s blog post says that men should listen to women, excluding women based on the tone argument is gross hypocrisy. Swearing Jeff makes a big deal of the fact that Shanley uses some profane language in her tweets. This combines a couple of different ways of silencing women. It s quite common for women to be held to a high standard of ladylike behavior, while men get a free pass on doing the same thing. One example of this is the Geek Feminism article about the results of Sarah Sharp s request for civility in the Linux kernel community [11]. That s not an isolated incident, to the best of my recollection in 20+ years my local Linux Users Group has had only one debate about profanity on mailing lists in that case a woman (who is no longer active in the group) was criticised for using lesser profanity than men used both before and after with no comment (as an experiment I used some gratuitous profanity a couple of weeks later and no-one commented). There is also a common difference in interpretation of expressions of emotion, when a woman seems angry then she invariably has men tell her to change her approach (even when there are obvious reasons for her anger) while when a man is angry the possibility that other people shouldn t make him angry will usually be considered. The issues related to the treatment of women have had a large affect on Shanley s life and her friend s lives. It s quite understandable that she is angry about this. Her use of profanity in tweets seems appropriate to the situation. Other Links Newsweek s Gentlemen in Technology article has a section about Jeff [12], it s interesting to note his history of deleting tweets and editing his post. I presume he will change his post in response to mine and not make any note of the differences. Jacob Kaplan-Moss wrote a good rebuttal to Jeff s post [13]. It s a good article and has some other relevant links that are worth reading.

• [1] http://etbe.coker.com.au/2012/04/23/autism-as-an-excuse/
• [2] http://etbe.coker.com.au/2010/12/08/empathy-autism-and-geeks/
• [3] http://geekfeminism.wikia.com/wiki/Autism_is_to_blame
• [4] https://medium.com/tech-culture-briefs/a1e93d985af0
• [5] https://twitter.com/shanley
• [6] http://blog.codinghorror.com/what-can-men-do/
• [7] http://idea.library.drexel.edu/bitstream/1860/2632/1/2006175339.pdf
• [8] http://en.wikipedia.org/wiki/Delusions_of_Gender
• [9] http://www.amazon.com/Delusions-Gender-Society-Neurosexism-Difference/dp/0393340244
• [10] http://geekfeminism.wikia.com/wiki/Tone_argument
• [11] http://geekfeminism.org/2013/09/05/tone-policing-a-tool-for-protecting-male-power/
• [12] http://www.newsweek.com/today-tabs-meet-gentlemen-technology-248696
• [13] http://jacobian.org/writing/what-can-men-do/

I hate the days when I wake up at odd hours for no good reason. This morning I woke up at 4:30am briefly, with no idea why. It makes me wonder if there was some sort of external noise, and that's what woke Zoe up yesterday morning. I got myself going at a reasonable hour this morning, and decided to walk to the Bulimba post office to collect a package that was waiting for me. It was a nice enough morning for a walk, and I'm glad I decided to do it. Along the way, I observed multiple grandmothers walking their grandchildren to school. I've been thinking a lot about next year lately. I feel very strongly about Zoe not having to go into after school care. It seems that one of the new societal norms is the grandparents have to step in with the school transportation and after school care. That's not going to be particularly practical in our situation though, so I'm currently leaning towards seeking some sort of flexible employment next year that will allow me to be able to be available after Zoe finishes school. I was fairly motivated to get stuck into my to do list after my walk. A long standing item was to cancel one of my remaining US credit cards, and the time difference worked out well to do that, so I finally took care of that. I then realised it was a good time for the US East Coast, so I did a Hangout with one of my best friends in New York. It was great to have a catch up. After that, I finished off my US tax return, and also sorted out some other stuff that needed finishing off. I had to go to the Valley to find a FedEx location, so I drove over there, and on the way back stopped off in Bulimba to get some Mother's Day cards. By that stage it was about time to pick up Zoe from Kindergarten, so I quickly grabbed some lunch and then drove over to pick her up. She didn't nap again today, so that made our departure from Kindergarten nice and easy. I'd booked both of us in for haircuts at 3pm, so we got home with enough time for Zoe to ride her scooter to the hairdresser. We had our haircuts and Zoe had a bit of a play in the play corner, and we headed back home. I'd bought a venus fly trap from Bunnings last week while we were picking up other bits and pieces. I wanted to show Zoe how they worked, so we watched a few YouTube videos. This one was particularly good. After that, we went down to the rubbish skip with our fly trap to see if we could catch any flies in it, but Zoe quickly lost interest. So we headed back upstairs, and triggered one with a toothpick. I probably could have done this on a Friday and called it a Science Friday activity with a botany bent. After that, we just watched some TV together on the couch until Sarah arrived to pick her up.