Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 1 hour 7 min ago

Matthew Garrett: Going my own way

3 hours 36 sec ago
Reaction to Sarah's post about leaving the kernel community was a mixture of terrible and touching, but it's still one of those things that almost certainly won't end up making any kind of significant difference. Linus has made it pretty clear that he's fine with the way he behaves, and nobody's going to depose him. That's unfortunate, because earlier today I was sitting in a presentation at Linuxcon and remembering how much I love the technical side of kernel development. "Remembering" is a deliberate choice of word - it's been increasingly difficult to remember that, because instead I remember having to deal with interminable arguments over the naming of an interface because Linus has an undying hatred of BSD securelevel, or having my name forever associated with the deepthroating of Microsoft because Linus couldn't be bothered asking questions about the reasoning behind a design before trashing it.

In the end it's a mixture of just being tired of dealing with the crap associated with Linux development and realising that by continuing to put up with it I'm tacitly encouraging its continuation, but I can't be bothered any more. And, thanks to the magic of free software, it turns out that I can avoid putting up with the bullshit in the kernel community and get to work on the things I'm interested in doing. So here's a kernel tree with patches that implement a BSD-style securelevel interface. Over time it'll pick up some of the power management code I'm still working on, and we'll see where it goes from there. But, until there's a significant shift in community norms on LKML, I'll only be there when I'm being paid to be there. And that's improved my mood immeasurably.


Gergely Nagy: What dh-exec is, and what it isn't for

3 hours 25 min ago

Strange as it may be, it turns out I never wrote about dh-exec yet, even though it is close to being four years old. Gosh, time flies so fast when you're having fun! Since its first introduction, there's been a reasonable uptake in dh-exec use: as of this writing, 129 packages build-depend on dh-exec. One might think this would be a cause for celebration, that the package is put to great use. But it's not.

You see, a significant number of those 129 packages are doing it wrong, and need not build-depend on dh-exec at all.

The purpose of dh-exec is to allow one to do things stock debhelper can't do, such as renaming files during the dh_install phase, or applying architecture or build profile based filtering, or doing environment variable substitution. There are many legit uses for all of these features, but there are some which can be easily solved without using dh-exec. So first, I'll talk a bit about the don'ts.

What not to use dh-exec for

One of the most abused part of dh-exec is its variable substitution feature, and it is often used without need, to install multiarch-related files. While that is one intended use-case, there are few situations currently in the archive that stock debhelper can't handle. Let me explain the situation!

Lets assume we have an upstream package, where the build system is something as common as autotools or CMake, for which debhelper can automatically set the appropriate flags and paths. Furthermore, lets assume that the upstream build system would install the following files:


We want to include the first two in the libalala1 package, the rest in libalala-dev, so what do we do? We use stock debhelper, of course!

  • libalala1.install:

  • libalala-dev.install:


That is all you need. In this case, there is absolutely no need for dh-exec. While using dh-exec without need is not much of an issue, because it only increases the space required for the build and build times by a tiny bit, I would still strongly recommend not introducing dh-exec needlessly. Why? Because of simplicity and aesthetics.

So, if you find yourself doing any of these, or similar, that's a sign you are doing things wrong:

usr/lib/${DEB_HOST_MULTIARCH}/*.so.* /usr/lib/${DEB_HOST_MULTIARCH}/
usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/*.pc /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
usr/lib/${DEB_HOST_MULTIARCH}/package/*.so /usr/lib/${DEB_HOST_MULTIARCH}/package

Unless there are other directories under usr/lib that are not the multiarch triplet, using stock debhelper and wildcards is not only more succinct, simpler and more elegant, but also lighter on resources required.

When dh-exec becomes usefulChanging installation paths

Once you want to change where things get installed, then dh-exec becomes useful:

usr/lib/*.so.* /usr/lib/${DEB_HOST_MULTIARCH}
usr/lib/${DEB_HOST_MULTIARCH}/package/* /usr/lib/${DEB_HOST_MULTIARCH}/package-plugins/
some/dir/*.so.* /usr/lib/${DEB_HOST_MULTIARCH}

This usually happens when upstream's build system can't easily be taught about multiarch paths. For most autotools and CMake-based packages, this is not the case.

Variable substitution

Consider this case:

/usr/share/octave/packages/mpi-${DEB_VERSION_UPSTREAM}/hello2dimmat.m /usr/share/doc/octave-mpi/examples/hello2dimmat.m
/usr/share/octave/packages/mpi-${DEB_VERSION_UPSTREAM}/hellocell.m /usr/share/doc/octave-mpi/examples/hellocell.m

Here, the build supplies ${DEB_VERSION_UPSTREAM}, and using dh-exec allows one to have a generic debian/links file, that does not need updating whenever the upstream version changes. We can't use wildcards here, because dh_link does not expand them.

Renaming files

In case one needs to rename files during the dh_install phase, dh-exec can be put to use for great results:

ssh-agent-filter.bash-completion => usr/share/bash-completion/completions/ssh-agent-filter

Sometimes one would wish to conditionally install something based on the architecture, or the build profile. In this case, dh-exec is the tool to turn to:

<!stage1 !stage2> ../../libdde-linux26/Makeconf* usr/share/libdde_linux26

usr/lib/gvfs/gvfsd-afc                                          [!hurd-any]
usr/lib/gvfs/gvfsd-gphoto2                                      [linux-any]

Norbert Preining: Craft Beer Kanazawa 2015 地ビール祭り・金沢

15 hours 42 min ago

Last weekend the yearly Craft Beer Kanazawa Festival took place in central Kanazawa. This year 14 different producers brought about 80 different kind of beers for us to taste. Compared with 6 years ago when I came to Japan and Japan was still more or less Kirin-Asahi-Sapporo country without any distinguishable taste, the situation as improved vastly, and we can now enjoy lots of excellent local beers!

Returning from a trip to Swansea and a conference in Fukuoka, I arrived at Kanazawa train station and went directly to the beer festival. A great welcome back in Kanazawa, but due to excessive sleep deprivation and the feeling of “finally I want to come home”, I only enjoyed 6 beers from 6 different producers.

In the gardens behind the Shinoki Cultural Center lots of small tents with beer and food were set up. Lots of tables and chairs were also available, but most people enjoyed flocking around in the grass around the tents. What a difference to last year’s rainy and cold beer festival!

This year’s producers were (in order from left to right, page links according to language):

With only 6 beers to my avail (due to ticket system), I choose the ones I don’t have nearby. Mind that the following comments are purely personal and do not define a quality standards I just say what I like from worst to best:

  • Ohya Brasserie, Kitokito Hop きときとホップ: A desaster, I was close to throw this beer away, but then thought – もったいない (what a waste!). Strange and disturbing taste.
  • Ushitora Brewery, Pure Street Session IPA: Ok, but nothing special. Too light and not taste a bit unclear to me.
  • Minoh Brewery, Momo Weizen: Typical Weizen Beer, light and refreshing taste. Good.
  • Swanlake Brewery, some seasonal IPA: good, not so extremely bitter, nice taste.
  • Ise Kadoya Brewery, Pale Ale: very good, full taste
  • Yoho Brewery, Red Ale: my absolute favorite – I don’t know why, but this brewery simply produces absolutely stunning ales. Their Aooni 青鬼 IPA is my day-in-day-out beer, world class. Their Yona Yona Ale, less bitter than the Aooni, is already famous, and this Red Ale was a perfect addition.

A great beer festival and I am looking for next years festival to try a few more. In the mean time I will stock up beers at home, so that I have always a good Yoho Brewery beer at hand!


Sune Vuorela: KDE at Qt World Summit

5 October, 2015 - 21:06

So. KDE has landed at Qt World Summit.

You can come and visit our booth and …

  • hear about our amazing Free Qt Addons (KDE Frameworks)
  • stories about our development tools
  • meet some of our developers
  • Talk about KDE in general
  • Or just say hi!

KDE – 19 years of Qt Experience.

Bálint Réczey: Debian success stories: Automated signature verification

5 October, 2015 - 18:41

Debian was not generally seen s a bleeding-edge distribution, but it offered a perfect combination of stability and up-to-date software in our field when we chose the platform for our signature verification project. Having an active Debian Developer in the team also helped ensuring that packages which we use were in good shape when the freeze, then the release came and we can still rely on Jessie images with only a few extra packages to run our software stack.

Not having to worry about the platform, we could concentrate on the core project and I’m proud to announce that our start-up‘s algorithm won this year’s Signature Verification Competition for Online Skilled Forgeries (SigWIComp2015) . The more detailed story can be read already in the English business news and is also on, a leading Hungarian news site. We are also working on a solution for categorizing users based on cursor/finger movements for targeting content, offers and ads better. This is also covered in the articles.

László – a signature comparable in quality to the reference signatures

The verification task was not easy. The reference signatures were recorded at very low resolution and frequency and the forgers did a very good job in forging them creating a true challenge for everyone competing. At first glance it is hard to imagine that there is usable information in such small amount of recorded data, but our software is already better than me, for example in telling the difference between genuine and forged signatures. It feels like when the chess program beats the programmer again and again.

I would like to thank you all, who helped making Debian an awesome universal operating system and hope we can keep making every release better and better!

Michal &#268;iha&#345;: python-suseapi 0.22

5 October, 2015 - 17:00

The python-suseapi 0.22 has been released last week. The version number shows nothing special, but one important change has happened - the development repository has been moved.

It's now under openSUSE project on GitHub, what makes it easier to find for potential users and also makes team maintenance a bit easier than under my personal account.

If you're curious what the module does - it's mostly usable only inside SUSE, providing access to some internal services. One major thing usable outside is the Bugzilla interface, which should be at one day replaced by python-bugzilla, but for now provides some features not available there (using web scraping).

Anyway the code has documentation on, so you can figure out yourself what it includes.

Filed under: Coding English SUSE | 0 comments

Julien Danjou: Gnocchi talk at OpenStack Paris Meetup #16

5 October, 2015 - 15:45

Last week, I've been invited to the OpenStack Paris meetup #16, whose subject was about metrics in OpenStack. Last time I spoke at this meetup was back in 2012, during the OpenStack Paris meetup #2. A very long time ago!

I talked for half an hour about Gnocchi, the OpenStack project I've been running for 18 months now. I started by explaining the story behind the project and why we needed to build it. Ceilometer has an interesting history and had a curious roadmap these last year, and I summarized that briefly. Then I talk about how Gnocchi works and what it offers to users and operators. The slides where full of JSON, but I imagine it offered a interesting view of what the API looks like and how easy it is to operate. This also allowed me to emphasize how many use cases are actually really covered and solved, contrary to what Ceilometer did so far. The talk has been well received and I got a few interesting questions at the end.

The video of the talk (in French) and my slides are available on my talk page and below. I hope you'll enjoy it.

Philipp Kern: Root on LVM on Debian s390x, new Hercules

5 October, 2015 - 04:08

Two s390x changes landed in Debian unstable today: With this it should be possible to install Debian on s390x with root on LVM. I'd be happy to hear feedback about installations with any configuration, be it root on a single DASD or root on LVM. Unless you set both mirror/udeb/suite and mirror/suite to unstable you'll need to wait until the changes are in testing, though. (The debian-installer build does not matter as zipl-installer is not part of the initrd and sysconfig-hardware is part of the installation.)
Furthermore I uploaded a new version of Hercules - a z/Architecture emulator - to get a few more years of maintenance into Debian. See its upstream changelog for details on the changes (old 3.07 → new 3.11).
At this point qemu at master is also usable for s390x emulation. It is much faster than Hercules, but it uses newfangled I/O subsystems like virtio. Hence we will need to do some more patching to make debian-installer just work. One patch for netcfg is in to support virtio networking correctly, but then it forces the user to configure a DASD. (Which would be as wrong if Fibre Channel were to be used.) In the end qemu and KVM on s390x look so much like a normal x86 VM that we could drop most of the special-casing of s390x (netcfg-static instead of netcfg; network-console instead of using the VM console; DASD configuration instead of simply using virtio-blk devices; I guess we get to keep zIPL for booting).

Dirk Eddelbuettel: RcppArmadillo

5 October, 2015 - 03:06

The somewhat regular monthly upstream Armadillo update brings us a first release of the 6.* series. This follows an earlier test release announced on the list, and released to the Rcpp drat. And as version 6.100.0 was released on Friday by Conrad, we rolled it into RcppArmadillo release yesterday. Following yet another full test against all reverse dependencies, got uploaded to CRAN which has now accepted it. A matching upload to Debian will follow shortly.

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab.

This release a few changes:

Changes in RcppArmadillo version (2015-10-03)
  • Upgraded to Armadillo 6.100.0 ("Midnight Blue")

    • faster norm() and normalise() when using ATLAS or OpenBLAS

    • added Schur decomposition: schur()

    • stricter handling of matrix objects by hist() and histc()

    • advanced constructors for using auxiliary memory by Mat, Col, Row and Cube now have the default of strict = false

    • Cube class now delays allocation of .slice() related structures until needed

    • expanded join_slices() to handle joining cubes with matrices

Courtesy of CRANberries, there is also a diffstat report for the most recent CRAN release. As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

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

Lunar: Reproducible builds: week 23 in Stretch cycle

5 October, 2015 - 00:09

What happened in the reproducible builds effort this week:

Toolchain fixes

Andreas Metzler uploaded autogen/1:5.18.6-1 in experimental with several patches for reproducibility issues written by Valentin Lorentz.

Groovy upstream has merged a change proposed by Emmanuel Bourg to remove timestamps generated by groovydoc.

Ben Hutchings submitted a patch to add support for SOURCE_DATE_EPOCH in linux-kbuild as an alternate way to specify the build timestamp.

Reiner Herrman has sent a patch adding support for SOURCE_DATE_EPOCH in docbook-utils.

Packages fixed

The following packages became reproducible due to changes in their build dependencies: commons-csv. fest-reflect, sunxi-tools, xfce4-terminal,

The following packages became reproducible after getting fixed:

Some uploads fixed some reproducibility issues but not all of them:

Patches submitted which have not made their way to the archive yet:

Tomasz Rybak uploaded pycuda/2015.1.3-1 which should fix reproducibility issues. The package has not been tested as it is in contrib.

akira found an embedded code copy of texi2html in fftw.

Email notifications are now only sent once a day per package, instead of on each status change. (h01ger)

disorderfs has been temporarily disabled to see if it had any impact on the disk space issues. (h01ger)

When running out of disk space, build nodes will now automatically detect the problem. This means test results will not be recorded as “FTBFS” and the problem will be reported to Jenkins maintainers. (h01ger)

The navigation menu of package pages has been improved. (h01ger)

The two amd64 builders now use two different kernel versions: 3.16 from stable and 4.1 from backports on the other. (h01ger)

We now graph the number of packages which needs to be fixed. (h01ger)

Munin now creates graphs on how many builds were performed by build nodes (example). (h01ger)

A migration plan has been agreed with DSA on how to turn Jenkins into an official Debian service. A backport of jenkins-job-builder for Jessie is currently missing. (h01ger)

Package reviews

119 reviews have been removed, 103 added and 45 updated this week.

16 “fail to build from source” issues were reported by Chris Lamb and Mattia Rizzolo.

New issue this week: timestamps_in_manpages_generated_by_docbook_utils.


Allan McRae has submitted a patch to make ArchLinux pacman record a .BULDINFO file.

Jonathan Carter: Long Overdue Debconf 15 Post

4 October, 2015 - 23:58

In August (that was 2 months ago, really!?) I attended DebCamp and DebConf in Heidelberg, Germany. This blog post is somewhat belated due to the debbug (flu obtained during DebConf) and all the catching up I had to do since then.


Debcamp was great, I got to hack on some of my Python related packages that were in need of love for a long time and also got to spend a lot of time tinkering with VLC for the Video Team. Even better than that, I caught up with a lot of great people I haven’t seen in ages (and met new ones) and stayed up waaaaay too late drinking beer, playing Mao and watching meteor showers.


At Debconf, I gave a short talk about AIMS Desktop (slides) but also expanded on the licensing problems we’ve had with Ubuntu on that project. Not all was bleak on the Ubuntu front though, some Ubuntu/Canonical folk were present at DebConf and said that they’d gladly get involved with porting Ubiquity (the Ubuntu installer, a front-end to d-i) to Debian. That would certainly be useful to many derivatives including potentiall AIMS Desktop if it were to move over to Debian.

AIMS Desktop talk slides:

We’re hosting DebConf in Cape Town next year and did an introduction during a plenary (slides). It was interesting spending some time with the DC15 team and learning how they work, it’s amazing all the detail they have to care about and how easy they made it look from the outside, I hope the DC16 team will pull that off as well.

Debconf 16 Slides:

DebConf 16 team members present at DebConf16 during DC16 presentation:

I uploaded my photos to DebConf Gallery, Facebook and Google, take your pick ;-), many sessions were recorded, catch them on If I had to summarize everything that I found interesting I’d have to delay posting this entry even further, topics that were particularly interesting were:

  • Reproducible Builds (project page on wiki)
  • Trademark Issues (general logo use discussion, and what can call itself “Debian”)
  • Many Derivative discussions
  • PPAs for Debian
  • Many packaging and workflow related talks and discussions where I was only qualified to listen and tried to take in as much as possible
Pollito’s First Trip to Africa

In my state of flu with complete lack of concentration for anything work related, I went ahead and made a little short story documenting Pollito’s (the DebConf mascot chicken) first trip to Africa. It’s silly but it was fun to make and some people enjoyed it ^_^

Well, what else can I say? DebConf 15 was a blast! Hope to see you at Debconf 16!

Johannes Schauer: new sbuild release 0.66.0

4 October, 2015 - 16:31

I just released sbuild 0.66.0-1 into unstable. It fixes a whopping 30 bugs! Thus, I'd like to use this platform to:

  • kindly ask all sbuild users to report any new bugs introduced with this release
  • give a big thank you to everybody who supplied the patches that made fixing this many bugs possible (in alphabetical order): Aurelien Jarno, Christian Kastner, Christoph Egger, Colin Watson, Dima Kogan, Guillem Jover, Luca Falavigna, Maria Valentina Marin Rordrigues, Miguel A. Colón Vélez, Paul Tagliamonte

And a super big thank you to Roger Leigh who, despite having resigned from Debian, was always available to give extremely helpful hints, tips, opinion and guidance with respect to sbuild development. Thank you!

Here is a list of the major changes since the last release:

  • add option --arch-all-only to build arch:all packages
  • environment variable SBUILD_CONFIG allows to specify a custom configuration file
  • add option --build-path to set a deterministic build path
  • fix crossbuild dependency resolution
  • add option --extra-repository-key for extra apt keys
  • add option --build-dep-resolver=aspcud for aspcud based resolver
  • allow complex commands as sbuild hooks
  • add now external command %SBUILD_SHELL produces an interactive shell
  • add options --build-deps-failed-commands, --build-failed-commands and --anything-failed-commands for more hooks

Stig Sandbeck Mathisen: Free software activities in September 2015

4 October, 2015 - 03:56

Working on making the munin master fit inside Mojolicious. The existing code is not written to make this trivial, but all the pieces are there. Most of the pieces need breaking up into smaller pieces to fit.

Debian Packaging

New version of puppet-module-puppetlabs-apache (Closes: #788124 #788125 #788127 ). I like it when a new upstream version closes all bugs left in the bts for a package.

A new package, the TLS proxy hitch currently waiting in the queue.


Lots of work on a new ceph puppet module.

Daniel Pocock: Want to be selected for Google Summer of Code 2016?

2 October, 2015 - 23:41

I've mentored a number of students in 2013, 2014 and 2015 for Debian and Ganglia and most of the companies I've worked with have run internships and graduate programs from time to time. GSoC 2015 has just finished and with all the excitement, many students are already asking what they can do to prepare and be selected for Outreachy or GSoC in 2016.

My own observation is that the more time the organization has to get to know the student, the more confident they can be selecting that student. Furthermore, the more time that the student has spent getting to know the free software community, the more easily they can complete GSoC.

Here I present a list of things that students can do to maximize their chance of selection and career opportunities at the same time. These tips are useful for people applying for GSoC itself and related programs such as GNOME's Outreachy or graduate placements in companies.


There is no guarantee that Google will run the program again in 2016 or any future year until the Google announcement.

There is no guarantee that any organization or mentor (including myself) will be involved until the official list of organizations is published by Google.

Do not follow the advice of web sites that invite you to send pizza or anything else of value to prospective mentors.

Following the steps in this page doesn't guarantee selection. That said, people who do follow these steps are much more likely to be considered and interviewed than somebody who hasn't done any of the things in this list.

Understand what free software really is

You may hear terms like free software and open source software used interchangeably.

They don't mean exactly the same thing and many people use the term free software for the wrong things. Not all projects declaring themselves to be "free" or "open source" meet the definition of free software. Those that don't, usually as a result of deficiencies in their licenses, are fundamentally incompatible with the majority of software that does use genuinely free licenses.

Google Summer of Code is about both writing and publishing your code and it is also about community. It is fundamental that you know the basics of licensing and how to choose a free license that empowers the community to collaborate on your code well after GSoC has finished.

Please review the definition of free software early on and come back and review it from time to time. The The GNU Project / Free Software Foundation have excellent resources to help you understand what a free software license is and how it works to maximize community collaboration.

Don't look for shortcuts

There is no shortcut to GSoC selection and there is no shortcut to GSoC completion.

The student stipend (USD $5,500 in 2014) is not paid to students unless they complete a minimum amount of valid code. This means that even if a student did find some shortcut to selection, it is unlikely they would be paid without completing meaningful work.

If you are the right candidate for GSoC, you will not need a shortcut anyway. Are you the sort of person who can't leave a coding problem until you really feel it is fixed, even if you keep going all night? Have you ever woken up in the night with a dream about writing code still in your head? Do you become irritated by tedious or repetitive tasks and often think of ways to write code to eliminate such tasks? Does your family get cross with you because you take your laptop to Christmas dinner or some other significant occasion and start coding? If some of these statements summarize the way you think or feel you are probably a natural fit for GSoC.

An opportunity money can't buy

The GSoC stipend will not make you rich. It is intended to make sure you have enough money to survive through the summer and focus on your project. Professional developers make this much money in a week in leading business centers like New York, London and Singapore. When you get to that stage in 3-5 years, you will not even be thinking about exactly how much you made during internships.

GSoC gives you an edge over other internships because it involves publicly promoting your work. Many companies still try to hide the potential of their best recruits for fear they will be poached or that they will be able to demand higher salaries. Everything you complete in GSoC is intended to be published and you get full credit for it. Imagine a young musician getting the opportunity to perform on the main stage at a rock festival. This is how the free software community works. It is a meritocracy and there is nobody to hold you back.

Having a portfolio of free software that you have created or collaborated on and a wide network of professional contacts that you develop before, during and after GSoC will continue to pay you back for years to come. While other graduates are being screened through group interviews and testing days run by employers, people with a track record in a free software project often find they go straight to the final interview round.

Register your domain name and make a permanent email address

Free software is all about community and collaboration. Register your own domain name as this will become a focal point for your work and for people to get to know you as you become part of the community.

This is sound advice for anybody working in IT, not just programmers. It gives the impression that you are confident and have a long term interest in a technology career.

Choosing the provider: as a minimum, you want a provider that offers DNS management, static web site hosting, email forwarding and XMPP services all linked to your domain. You do not need to choose the provider that is linked to your internet connection at home and that is often not the best choice anyway. The XMPP foundation maintains a list of providers known to support XMPP.

Create an email address within your domain name. The most basic domain hosting providers will let you forward the email address to a webmail or university email account of your choice. Configure your webmail to send replies using your personalized email address in the From header.

Update your ~/.gitconfig file to use your personalized email address in your Git commits.

Create a web site and blog

Start writing a blog. Host it using your domain name.

Some people blog every day, other people just blog once every two or three months.

Create links from your web site to your other profiles, such as a Github profile page. This helps reinforce the pages/profiles that are genuinely related to you and avoid confusion with the pages of other developers.

Many mentors are keen to see their students writing a weekly report on a blog during GSoC so starting a blog now gives you a head start. Mentors look at blogs during the selection process to try and gain insight into which topics a student is most suitable for.

Create a profile on Github

Github is one of the most widely used software development web sites. Github makes it quick and easy for you to publish your work and collaborate on the work of other people. Create an account today and get in the habbit of forking other projects, improving them, committing your changes and pushing the work back into your Github account.

Github will quickly build a profile of your commits and this allows mentors to see and understand your interests and your strengths.

In your Github profile, add a link to your web site/blog and make sure the email address you are using for Git commits (in the ~/.gitconfig file) is based on your personal domain.

Start using PGP

Pretty Good Privacy (PGP) is the industry standard in protecting your identity online. All serious free software projects use PGP to sign tags in Git, to sign official emails and to sign official release files.

The most common way to start using PGP is with the GnuPG (GNU Privacy Guard) utility. It is installed by the package manager on most Linux systems.

When you create your own PGP key, use the email address involving your domain name. This is the most permanent and stable solution.

Print your key fingerprint using the gpg-key2ps command, it is in the signing-party package on most Linux systems. Keep copies of the fingerprint slips with you.

This is what my own PGP fingerprint slip looks like. You can also print the key fingerprint on a business card for a more professional look.

Using PGP, it is recommend that you sign any important messages you send but you do not have to encrypt the messages you send, especially if some of the people you send messages to (like family and friends) do not yet have the PGP software to decrypt them.

If using the Thunderbird (Icedove) email client from Mozilla, you can easily send signed messages and validate the messages you receive using the Enigmail plugin.

Get your PGP key signed

Once you have a PGP key, you will need to find other developers to sign it. For people I mentor personally in GSoC, I'm keen to see that you try and find another Debian Developer in your area to sign your key as early as possible.

Free software events

Try and find all the free software events in your area in the months between now and the end of the next Google Summer of Code season. Aim to attend at least two of them before GSoC.

Look closely at the schedules and find out about the individual speakers, the companies and the free software projects that are participating. For events that span more than one day, find out about the dinners, pub nights and other social parts of the event.

Try and identify people who will attend the event who have been GSoC mentors or who intend to be. Contact them before the event, if you are keen to work on something in their domain they may be able to make time to discuss it with you in person.

Take your PGP fingerprint slips. Even if you don't participate in a formal key-signing party at the event, you will still find some developers to sign your PGP key individually. You must take a photo ID document (such as your passport) for the other developer to check the name on your fingerprint but you do not give them a copy of the ID document.

Events come in all shapes and sizes. FOSDEM is an example of one of the bigger events in Europe, is a similarly large event in Australia. There are many, many more local events such as the Debian UK mini-DebConf in Cambridge, November 2015. Many events are either free or free for students but please check carefully if there is a requirement to register before attending.

On your blog, discuss which events you are attending and which sessions interest you. Write a blog during or after the event too, including photos.

Quantcast generously hosted the Ganglia community meeting in San Francisco, October 2013. We had a wild time in their offices with mini-scooters, burgers, beers and the Ganglia book. That's me on the pink mini-scooter and Bernard Li, one of the other Ganglia GSoC 2014 admins is on the right.

Install Linux

GSoC is fundamentally about free software. Linux is to free software what a tree is to the forest. Using Linux every day on your personal computer dramatically increases your ability to interact with the free software community and increases the number of potential GSoC projects that you can participate in.

This is not to say that people using Mac OS or Windows are unwelcome. I have worked with some great developers who were not Linux users. Linux gives you an edge though and the best time to gain that edge is now, while you are a student and well before you apply for GSoC.

If you must run Windows for some applications used in your course, it will run just fine in a virtual machine using Virtual Box, a free software solution for desktop virtualization. Use Linux as the primary operating system.

Here are links to download ISO DVD (and CD) images for some of the main Linux distributions:

If you are nervous about getting started with Linux, install it on a spare PC or in a virtual machine before you install it on your main PC or laptop. Linux is much less demanding on the hardware than Windows so you can easily run it on a machine that is 5-10 years old. Having just 4GB of RAM and 20GB of hard disk is usually more than enough for a basic graphical desktop environment although having better hardware makes it faster.

Your experiences installing and running Linux, especially if it requires some special effort to make it work with some of your hardware, make interesting topics for your blog.

Decide which technologies you know best

Personally, I have mentored students working with C, C++, Java, Python and JavaScript/HTML5.

In a GSoC program, you will typically do most of your work in just one of these languages.

From the outset, decide which language you will focus on and do everything you can to improve your competence with that language. For example, if you have already used Java in most of your course, plan on using Java in GSoC and make sure you read Effective Java (2nd Edition) by Joshua Bloch.

Decide which themes appeal to you

Find a topic that has long-term appeal for you. Maybe the topic relates to your course or maybe you already know what type of company you would like to work in.

Here is a list of some topics and some of the relevant software projects:

  • System administration, servers and networking: consider projects involving monitoring, automation, packaging. Ganglia is a great community to get involved with and you will encounter the Ganglia software in many large companies and academic/research networks. Contributing to a Linux distribution like Debian or Fedora packaging is another great way to get into system administration.
  • Desktop and user interface: consider projects involving window managers and desktop tools or adding to the user interface of just about any other software.
  • Big data and data science: this can apply to just about any other theme. For example, data science techniques are frequently used now to improve system administration.
  • Business and accounting: consider accounting, CRM and ERP software.
  • Finance and trading: consider projects like R, market data software like OpenMAMA and connectivity software (Apache Camel)
  • Real-time communication (RTC), VoIP, webcam and chat: look at the JSCommunicator or the Jitsi project
  • Web (JavaScript, HTML5): look at the JSCommunicator

Before the GSoC application process begins, you should aim to learn as much as possible about the theme you prefer and also gain practical experience using the software relating to that theme. For example, if you are attracted to the business and accounting theme, install the PostBooks suite and get to know it. Maybe you know somebody who runs a small business: help them to upgrade to PostBooks and use it to prepare some reports.

Make something

Make some small project, less than two week's work, to demonstrate your skills. It is important to make something that somebody will use for a practical purpose, this will help you gain experience communicating with other users through Github.

For an example, see the servlet Juliana Louback created for fixing phone numbers in December 2013. It has since been used as part of the Lumicall web site and Juliana was selected for a GSoC 2014 project with Debian.

There is no better way to demonstrate to a prospective mentor that you are ready for GSoC than by completing and publishing some small project like this yourself. If you don't have any immediate project ideas, many developers will also be able to give you tips on small projects like this that you can attempt, just come and ask us on one of the mailing lists.

Ideally, the project will be something that you would use anyway even if you do not end up participating in GSoC. Such projects are the most motivating and rewarding and usually end up becoming an example of your best work. To continue the example of somebody with a preference for business and accounting software, a small project you might create is a plugin or extension for PostBooks.

Getting to know prospective mentors

Many web sites provide useful information about the developers who contribute to free software projects. Some of these developers may be willing to be a GSoC mentor.

For example, look through some of the following:

Getting on the mentor's shortlist

Once you have identified projects that are interesting to you and developers who work on those projects, it is important to get yourself on the developer's shortlist.

Basically, the shortlist is a list of all students who the developer believes can complete the project. If I feel that a student is unlikely to complete a project or if I don't have enough information to judge a student's probability of success, that student will not be on my shortlist.

If I don't have any student on my shortlist, then a project will not go ahead at all. If there are multiple students on the shortlist, then I will be looking more closely at each of them to try and work out who is the best match.

One way to get a developer's attention is to look at bug reports they have created. Github makes it easy to see complaints or bug reports they have made about their own projects or other projects they depend on. Another way to do this is to search through their code for strings like FIXME and TODO. Projects with standalone bug trackers like the Debian bug tracker also provide an easy way to search for bug reports that a specific person has created or commented on.

Once you find some relevant bug reports, email the developer. Ask if anybody else is working on those issues. Try and start with an issue that is particularly easy and where the solution is interesting for you. This will help you learn to compile and test the program before you try to fix any more complicated bugs. It may even be something you can work on as part of your academic program.

Find successful projects from the previous year

Contact organizations and ask them which GSoC projects were most successful. In many organizations, you can find the past students' project plans and their final reports published on the web. Read through the plans submitted by the students who were chosen. Then read through the final reports by the same students and see how they compare to the original plans.

Start building your project proposal now

Don't wait for the application period to begin. Start writing a project proposal now.

When writing a proposal, it is important to include several things:

  • Think big: what is the goal at the end of the project? Does your work help the greater good in some way, such as increasing the market share of Linux on the desktop?
  • Details: what are specific challenges? What tools will you use?
  • Time management: what will you do each week? Are there weeks where you will not work on GSoC due to vacation or other events? These things are permitted but they must be in your plan if you know them in advance. If an accident or death in the family cut a week out of your GSoC project, which work would you skip and would your project still be useful without that? Having two weeks of flexible time in your plan makes it more resilient against interruptions.
  • Communication: are you on mailing lists, IRC and XMPP chat? Will you make a weekly report on your blog?
  • Users: who will benefit from your work?
  • Testing: who will test and validate your work throughout the project? Ideally, this should involve more than just the mentor.

If your project plan is good enough, could you put it on Kickstarter or another crowdfunding site? This is a good test of whether or not a project is going to be supported by a GSoC mentor.

Learn about packaging and distributing software

Packaging is a vital part of the free software lifecycle. It is very easy to upload a project to Github but it takes more effort to have it become an official package in systems like Debian, Fedora and Ubuntu.

Packaging and the communities around Linux distributions help you reach out to users of your software and get valuable feedback and new contributors. This boosts the impact of your work.

To start with, you may want to help the maintainer of an existing package. Debian packaging teams are existing communities that work in a team and welcome new contributors. The Debian Mentors initiative is another great starting place. In the Fedora world, the place to start may be in one of the Special Interest Groups (SIGs).

Think from the mentor's perspective

After the application deadline, mentors have just 2 or 3 weeks to choose the students. This is actually not a lot of time to be certain if a particular student is capable of completing a project. If the student has a published history of free software activity, the mentor feels a lot more confident about choosing the student.

Some mentors have more than one good student while other mentors receive no applications from capable students. In this situation, it is very common for mentors to send each other details of students who may be suitable. Once again, if a student has a good Github profile and a blog, it is much easier for mentors to try and match that student with another project.


Getting into the world of software engineering is much like joining any other profession or even joining a new hobby or sporting activity. If you run, you probably have various types of shoe and a running watch and you may even spend a couple of nights at the track each week. If you enjoy playing a musical instrument, you probably have a collection of sheet music, accessories for your instrument and you may even aspire to build a recording studio in your garage (or you probably know somebody else who already did that).

The things listed on this page will not just help you walk the walk and talk the talk of a software developer, they will put you on a track to being one of the leaders. If you look over the profiles of other software developers on the Internet, you will find they are doing most of the things on this page already. Even if you are not selected for GSoC at all or decide not to apply, working through the steps on this page will help you clarify your own ideas about your career and help you make new friends in the software engineering community.

Norbert Preining: Updates for OSX 10.11 El Capitan: cjk-gs-integrate and jfontmaps 20151002.0

2 October, 2015 - 14:52

Now that OSX 10.11 El Capitan is released and everyone is eagerly updating, in cooperation with the colleagues from the Japanese TeX world we have released new versions of the jfontmaps and cjk-gs-integrate packages. With these two packages in TeX Live, El Capitan users can take advantage of the newly available fonts in the Japanese TeX engines ((u)ptex et al), and directly in Ghostscript.

For jfontmaps the changes were minimal, Yusuke Terada fixed a mismatch in ttc index numbers for some fonts. Without this fix, Hiragino Interface is used instead of HiraginoSans-W3 and -W6.

On the other hand, cjk-gs-integrate has seen a lot more changes:

  • add support for OSX 10.11 El Capitan provided fonts (by Yusuke Terada)
  • added 2004-{H,V} encodings for Japanese fonts (by Munehiro Yamamoto)
  • fix incorrect link name – this prevented kanji-config-updmap from the jfontmaps package to find and use the linked fonts
  • rename --link-texmflocal to --link-texmf [DIR] with an optional argument
  • add a --remove option to revert the operation – this does clean up completely only if the same set of fonts is found

For more explanations concerning how to run cjk-gs-integrate, please see the dedicated page: CJK fonts and Ghostscript integration.

For feedback and bug reports, please use the github project pages: jfontmaps, cjk-gs-support.

Both packages should arrive in your local TeX Live CTAN repository within a day or two.

We hope that with this users of El Capitan can use their fonts to the full extend.


Junichi Uekawa: Playing with FUSE and git.

2 October, 2015 - 04:58
Playing with FUSE and git. I've been playing with FUSE and git to make a file system, for fun. There's already many filesystems that are implemented with FUSE, and there are quite a few ones that implement filesystem for git, but I don't use any of them. I wondered why that is the case but tried to build one anyway. It's in github repository gitlstreefs. I have created several toy file systems in C++. ninjafs is one where it shows ninja targets as files and builds the file target when file is actually needed. They aren't quite as useful yet but an interesting excercise, FUSE was reasonably straightforward to implement simple filesystems with.

Sylvain Beucler: Android Free developer tools rebuilds

1 October, 2015 - 19:41

I published some Free rebuilds of the Android SDK, NDK and ADT at:

As described in my previous post, Google is click-wrapping all developer binaries (including preview versions for which source code isn't published yet) with a non-free EULA, notably an anti-fork clause.

There's been some discussion on where to host this project at the campaign list.

Build instructions are provided, so feel free to check if the builds are reproducible, and contribute instructions for more tools!

Petter Reinholdtsen: French Docbook/PDF/EPUB/MOBI edition of the Free Culture book

1 October, 2015 - 18:20

As I wrap up the Norwegian version of Free Culture book by Lawrence Lessig (still waiting for my final proof reading copy to arrive in the mail), my great dblatex helper and developer of the dblatex docbook processor, Benoît Guillon, decided a to try to create a French version of the book. He started with the French translation available from the Wikilivres wiki pages, and wrote a program to convert it into a PO file, allowing the translation to be integrated into the po4a based framework I use to create the Norwegian translation the the English edition. We meet on the #dblatex IRC channel to discuss the work. If you want to help create a French edition, check out his git repository and join us on IRC. If the French edition look good, we might publish it as a paper book on A French version of the drawings and the cover need to be provided for this to happen.

Mike Gabriel: My FLOSS activities in August/September 2015

1 October, 2015 - 18:18

Here comes my "monthly" FLOSS report for August and September 2015. As 50% of August 2015 had been dedicated to taking some time off (spending time in Sweden with the family), it happened that even more workload had to be processed in September 2015.

  • Completion of MATE 1.10 in Debian testing/unstable and Ubuntu 15.10
  • Contribution to Debian LTS, Debian packaging
  • Development of GOsa² Plugin SchoolManager
  • Automatic builds for Arctica Project
  • Forking Unity Greeter as Arctica Greeter (with focus on the remote logon part inside Unity Greeter)
Received Sponsorship

My monthly 8h portion of working for the Debian LTS project I had to dispatch from August into September. Thus, I received 16h of paid work for working on Debian LTS in September 2015. For details, see below. Thanks to Raphael Hertzog for having me on the team [1]. Thanks to all the people and companies sponsoring the Debian LTS Team's work.

The development of GOsa² Plugin SchoolManager (for details, see below) was done on contract for a school in Nothern Germany. The code will be released under the same license as the GOsa² software itself.

Completion of MATE 1.10 in Debian testing/unstable and Ubuntu 15.10

In the first half of September all MATE 1.10 package finally landed in Debian testing (aka stretch). Martin Wimpress handled most the packaging changes, whereas my main job was being reviewer and uploader of his efforts. Thanks to John Paul Adrian Glaubitz for jumping in as reviewer and uploader during my vacation time.

read more

Mike Gabriel: Nightly builds for Arctica Project (Debian / Ubuntu)

1 October, 2015 - 17:42

I am happy to announce that The Arctica Project can now provide automatic nightly builds of its developers' coding code work.

Packages are built automatically via Jenkins, see [1] for an overview of the current build queues. The Jenkins system builds code as found on our CGit mirror site [2].

NOTE: The Arctica Project's nightly builds may especially be interesting to people that want to try out the latest development steps on nx-libs (3.6.x branch) as we provide nx-libs 3.6.x binary preview builds.

Currently, we only build our code against Debian and Ubuntu (amd64, i386), more distros and platforms are likely to be added. If people can provide machine power (esp. non-Intel based architectures), please get in touch with us on Freenode IRC (channel: #arctica).

This is how you can add our package repositories to your APT system.

Debian APT (here: stretch)

Please note that we only support recent Debian versions (currently version 7.x and above).

$ echo 'deb stretch main' | sudo tee /etc/apt/sources.list.d/arctica.list
sudo apt-key adv --recv-keys --keyserver 0x98DE3101
apt-get update
Ubuntu APT (here: trusty)

Please note that we support recent Ubuntu LTS versions only (Ubuntu 14.04 only at the moment).

$ echo 'deb trusty main' | sudo tee /etc/apt/sources.list.d/arctica.list
sudo apt-key adv --recv-keys --keyserver 0x98DE3101
apt-get update


read more


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้