Go to the content


Full screen Suggest an article
 RSS feed

Planet Debian

July 1, 2016 14:34 , by valessiobrito - | No one following this article yet.

Planet.Debian is a website that aggregates the blogs of many Debian contributors. Planet maintainers can be reached at planet at debian.org

Tim Retout: Jenkins milestone steps do not work yet

August 14, 2017 14:57, by Planet Debian - 0no comments yet

Public Service Announcement for anyone relying on Jenkins for continuous deployment - the milestone step plugin as of version 1.3.1 will not function correctly if you could have more than two builds running at once - older builds could get deployed after newer builds.

See JENKINS-46097.

A possible workaround is to add an initial milestone at the start of the pipeline, which will then allow builds to be killed early. (Builds are only killed early once they have passed their first milestone.)

Going by the source history, I reckon this bug has been present since the milestone-step plugin was created.

Dirk Eddelbuettel: RProtoBuf 0.4.10

August 13, 2017 22:08, by Planet Debian - 0no comments yet

RProtoBuf provides R bindings for the Google Protocol Buffers ("ProtoBuf") data encoding and serialization library used and released by Google, and deployed fairly widely in numerous projects as a language and operating-system agnostic protocol.

A new releases RProtoBuf 0.4.10 just appeared on CRAN. It is a maintenance releases replacing one leftover errorenous use of package= in .Call with the correct PACKAGE= (as requsted by CRAN). It also integrates a small robustification in the deserializer when encountering invalide objects; this was both reported and fixed by Jeffrey Shen.

Changes in RProtoBuf version 0.4.10 (2017-08-13)

  • More careful operation in deserializer checking for a valid class attribute (Jeffrey Shen in #29 fixing #28)

  • At the request of CRAN, correct one .Call() argument to PACKAGE=; update routine registration accordingly

CRANberries also provides a diff to the previous release. The RProtoBuf page has an older package vignette, a 'quick' overview vignette, a unit test summary vignette, and the pre-print for the JSS paper. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.

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

Lars Wirzenius: Retiring Obnam

August 13, 2017 18:49, by Planet Debian - 0no comments yet

This is a difficult announcement to write. The summary is if you use Obnam you should switch to another backup program in the coming months.

The first commit to Obnam's current code base is this:

commit 7eaf5a44534ffa7f9c0b9a4e9ee98d312f2fcb14
Author: Lars Wirzenius <liw@iki.fi>
Date:   Wed Sep 6 18:35:52 2006 +0300

    Initial commit.

It's followed by over 5200 more commits until the latest one, which is from yesterday. The NEWS file contains 58 releases. There are 20761 lines of Python, 15384 words in the English language manual, with translations in German and French. The yarn test suite, which is a kind of a manual, is another 13382 words in English and pseudo-English. That's a fair bit of code and prose. Not all of it mine, I've had help from some wonderful people. But most of it mine.

I wrote all of that because backups were fun. It was pleasing to use my own program to guarantee the safety of my own data. The technical challenges of implmenting the kind of backup program I wanted were interesting, and solving interesting problems is a big part of why I am a programmer.

Obnam has a kind user base. It's not a large user base: the Debian "popularity contest" service estimates it at around 500. But it's a user base that is kind and has treated me well. I have tried to reciprocate.

Unfortunately, I have not had fun while developing Obnam for some time now. This has changed. A few years ago, I lived in Manchester, UK, and commuted by train to work. It was a short train ride, about 15 minutes. At times I would sit on the floor with my laptop on my knees, writing code or the manual. Back then Obnam was a lot of fun. I was excited, and enthusiastic.

In the past two years or so, I've not been able to feel that excitement again. My native language, Finnish, has an expression describing unpleasant tasks: something is as much fun as drinking tar. That describes Obnam in recent years for me.

Obnam has not turned out well, from a maintainability point of view. It seems that every time I try to fix something, I break something else. Usuaully what breaks is speed or memory use: Obnam gets slower or starts using even more memory.

For several years now I've been working on a new repository format for Obnam, code names GREEN ALBATROSS. It was meant to solve Obnam's problems as far as extensibility, performance, and resource use were concerned. It seems to have failed.

I'm afraid I've had enough. I'm going to retire Obnam as a project and as a program, and move on to doing something else, so I can feel excitement and pleasure again.

After some careful thought, I fear that the maintainability problems of Obnam can realistically only be solved by a complete rewrite from scratch, and I'm not up to doing that.

If you use Obnam, you should migrate to some other backup solution. Don't worry, you have until the end of the year. I will be around and I intend to fix any serious bugs in Obnam; in particular, security flaws. But you should start looking for a replacement sooner rather than later.

I will be asking Obnam to be removed from the Debian unstable and testing branches. The next Debian release (buster, Debian 10) won't include Obnam.

The Obnam mailing lists are kindly hosted by Daniel Silverstone, and they will remain, but later this year I will change them to be moderated. The Obnam git repository will remain. The web site will remain, but I will add a note that Obnam is no longer maintained. Other Obnam online resources may disappear.

If you would like to take over the Obnam project, and try to resolve the various issues, please contact me to discuss that.

Thank you, and may you never need to restore.

Mike Gabriel: @DebConf17: Ad-hoc BoF: Debian for the Remote Desktop

August 13, 2017 15:57, by Planet Debian - 0no comments yet

On Thursday at DebConf17, all people interested in using this or that Remote Desktop solution on Debian (as a server, as a client, as both) came together for a BoF.

Sharing about Usage Scenarios

Quite some time we informally shared with one another what technologies and software we use for remote access to Debian machines and what the experiences are.

The situation in Debian and on GNU/Linux in general is that many technical approaches exist, all of them have certain features and certain limitations. The composition of features and limitations finally lead the users to choosing one or another technology as his or her favourite solution.

The Debian Remote Maintainers Team

On the developers' side, Dominik George and I set up a packaging team for Remote Desktop related software in Debian. A packaging team that we invite everyone who is maintaining such software in the widest sense to join: https://qa.debian.org/developer.php?login=pkg-remote-team%40lists.alioth...

'DebianRemote' namespace on the Debian Wiki

For users of Debian, the group agreed, we need an overview page (on wiki.debian.org) that provides an entry point for Debian on the Remote Desktop. An entry point that provides user information as well as developer information.

A skeleton of this wiki page, I have just set up (thanks to Vagrant for taking some notes in Gobby during the BoF): https://wiki.debian.org/DebianRemote

However, the page still contains loads of FIXMEs, so the actual work only now really starts. Fill the template with content (and also adapt the template, if needed).

Everyone with experience and know-how about Remote Desktop on Debian systems is invited to share knowledge and improve this wiki namespace. (I will, at the earliest, start working on Arctica, X2Go and NX passages end of August, but I'll be also happy to find passages having been written down that I can review by then).

Tracking Debian Remote Issues in Debian BTS

At the BoF, also the following suggestions came up: The Remote Desktop experience on a GNU/Linux desktop or terminal server can be affected by all graphical applications available. Often it happens, that a change in this or that graphical application results in problems in remote sessions, but not so in local sessions. We agreed on filing and tagging such bugs accordingly. For new bugs, please file such bugs with the following BTS header at the top of your mail and always explain what remote desktop solution is being used when the bug appears:

Package: file
Version: 1:5.19-2
Severity: important
User: debian-edu@lists.debian.org
Usertags: debian-edu


Overall, I was quite happy that the BoF has been attended by so many people and to see that there is quite "a lobby" in Debian. Let's dive into the work and make Debian 10 the first Debian, that mentions the Remote Desktop in its release notes.

Let's, in fact, release Debian 10 as the first Debian with the official announcement as an operating system for the Remote Desktop (like the Fedora people did already for Fedora 20).

Enrico Zini: Consensually doing things together?

August 13, 2017 14:26, by Planet Debian - 0no comments yet

On 2017-08-06 I have a talk at DebConf17 in Montreal titled "Consensually doing things together?" (video). Here are the talk notes.


At DebConf Heidelberg I talked about how Free Software has a lot to do about consensually doing things together. Is that always true, at least in Debian?

I’d like to explore what motivates one to start a project and what motivates one to keep maintaining it. What are the energy levels required to manage bits of Debian as the project keeps growing. How easy it is to say no. Whether we have roles in Debian that require irreplaceable heroes to keep them going. What could be done to make life easier for heroes, easy enough that mere mortals can help, or take their place.

Unhappy is the community that needs heroes, and unhappy is the community that needs martyrs.

I’d like to try and make sure that now, or in the very near future, Debian is not such an unhappy community.

Consensually doing things together

I gave a talk in Heidelberg.

Valhalla made stickers

Debian France distributed many of them.

There's one on my laptop.

Which reminds me of what we ought to be doing.

Of what we have a chance to do, if we play our cards right.

I'm going to talk about relationships. Consensual relationships.

Relationships in short.

Nonconsensual relationships are usually called abuse.

I like to see Debian as a relationship between multiple people.

And I'd like it to be a consensual one.

I'd like it not to be abuse.


From wikpedia:

In Canada "consent means…the voluntary agreement of the complainant to engage in sexual activity" without abuse or exploitation of "trust, power or authority", coercion or threats.[7] Consent can also be revoked at any moment.[8]»

There are 3 pillars often included in the description of sexual consent, or "the way we let others know what we're up for, be it a good-night kiss or the moments leading up to sex."

They are:

  • Knowing exactly what and how much I'm agreeing to
  • Expressing my intent to participate
  • Deciding freely and voluntarily to participate[20]

Saying "I've decided I won't do laundry anymore" when the other partner is tired, or busy doing things.

Is different than saying "I've decided I won't do laundry anymore" when the other partner has a chance to say "why? tell me more" and take part in negotiation.



Debian is the Universal Operating System.

Debian is made and maintained by people.

The long term health of debian is a consequence of the long term health of the relationship between Debian contributors.

Debian doesn't need to be technically perfect, it needs to be socially healthy.

Technical problems can be fixed by a healty community.

graph showing relationship between avoidance, accomodation, compromise, competition, collaboration

The Thomas-Kilmann Conflict Mode Instrument: source png.


Quick poll:

  • how many of you do things in Debian because you want to?
  • how many of you do things in Debian because you have to?
  • how many of you do both?

What are your motivations to be in a relationship?

Which of those motivations are healthy/unhealthy?

  • healthy sustain the relationship
  • unhealthy may explode spectacularly at some point

"Galadriel" (noun, by Francesca Ciceri): a task you have to do otherwise Sauron takes over Middle Earth

See: http://blog.zouish.org/nonupdd/#/22/1

What motivates me to start a project or pick one up?

  • I have an idea for for something fun or useful
  • I see something broken and I have an idea how to fix it

What motivates me to keep maintaning a project?

  • Nobody else can do it
  • Nobody else can be trusted to do it
  • Nobody else who can and can be trusted to do it is doing it
  • Somebody is paying me to do it

What motivates you?

What's an example of a sustainable motivation?

  • it takes me little time?
  • it's useful for me
  • It's fun
  • It saves me time to keep something running that if it breaks when I or somebody else needs it
  • it makes me feel useful? (then if I stop, I become useless, then I can't afford to stop?)
  • Getting positive feedback (more "you're good" than "i use it") ?

Is it really all consensual in Debian?

  • what tasks are done by people motivated by guilt / motivated by Galadriel?
  • if I volunteer to help team X that is in trouble, will I get stuck doing all the work as soon as people realise things move fine again and finally feel free to step back?


Energy that thing which is measured in spoons. The metaphore comes from people suffering with chronic health issues:

"Spoons" are a visual representation used as a unit of measure used to quantify how much energy a person has throughout a given day. Each activity requires a given number of spoons, which will only be replaced as the person "recharges" through rest. A person who runs out of spoons has no choice but to rest until their spoons are replenished.

For example, in Debian, I could spend:

  • Routine task: 1 spoon
  • Context switch: 2 spoons
  • New corner case: 5 spoons
  • Well written bug report: -1 spoon
  • Intersting thread: -1 spoon
  • New flamewar: 3 spoons

What is one person capable of doing?

  • are the things that we expect a person to do the things that one person can do?
  • having a history of people who can do it anyway is no excuse: show compassion to those people, take some of their work, thank them, but don't glorify them

Have reasonable expectations, on others:

  • If someone is out of spoons, they're out of spoons; they don't get more spoons if you insist; if you insist, you probably take even more spoons from them
  • If someone needs their spoons for something else, they are entitled to
  • If someone gets out of spoons for something important, and nobody else can do it, it's not their fault but a shared responsibility

Have reasonable expectations, on yourself:

  • If you are out of spoons, you are out of spoons
  • If you need spoons for something else, use them for something else
  • If you are out of spoons for something important, and nobody else can do it, it's not your problem, it's a problem in the community

Debian is a shared responsibility

  • Don't expect few people to take care of everything
  • Leave space for more people to take responsibility for things
  • Turnover empowers
  • Humans are a renewable resource, but only if you think of them that way

When spoons are limited, what takes more energy tends not to get done

  • routine is ok
  • non-routine tends to get stuck in the mailbox waiting for a day with more free time
    • are we able to listen when tricky cases happen?
    • are we able to respond when tricky cases happen?
    • are we able to listen/respond when socially tricky cases happen?
    • are we able to listen/respond when harassment happens?
    • can we tell people raising valid issues from troublemakers?
  • in NM
    • it's easier to accept a new maintainer than to reject them
    • it's hard or impossible to make a call on a controversial candidate when one doesn't know that side of Debian
  • I'm tired, why you report a bug? I don't want to deal with your bug. Maybe you are wrong and your bug is invalid? It would be good if you were wrong and your bug was invalid.
  • even politeness goes when out of spoons because it's too much effort

As the project grows, project-wide tasks become harder

Are they still humanly achievable?

  • release team
  • DAM (amount of energy to deal with when things go wrong; only dealing with when things go spectacularly wrong?)
  • DPL (how many people candidate to this year elections?)

I don't want Debian to have positions that require hero-types to fill them

  • heroes are rare
  • heroes are hard to replace
  • heroes burn out
  • heroes can become martyrs
  • heroes can become villains
  • heroes tend to be accidents waiting to happen

Dictatorship of who has more spoons:

  • Someone who has a lot of energy can take more and more tasks out of people who have less, and slowly drive all the others away
  • Good for results, bad for the team
  • Then we have another person who is too big to fail, and another accident waiting to happen


You are in a relationship that is just perfect. All your friends look up to you. You give people relationship advice. You are safe in knowing that You Are Doing It Right.

Then one day you have an argument in public.

You don't just have to deal with the argument, but also with your reputation and self-perception shattering.

One things I hate about Debian: consistent technical excellence.

I don't want to be required to always be right.

One of my favourite moments in the history of Debian is the openssl bug

Debian doesn't need to be technically perfect, it needs to be socially healthy, technical problems can be fixed.

I want to remove perfectionism from Debian: if we discover we've been wrong all the time in something important, it's not the end of Debian, it's the beginning of an improved Debian.

Too good to be true

There comes a point in most people's dating experience where one learns that when some things feel too good to be true, they might indeed be.

There are people who cannot say no:

  • you think everything is fine, and you discover they've been suffering all the time and you never had a clue

There are people who cannot take a no:

  • They depend on a constant supply of achievement or admiration to have a sense of worth, therefore have a lot of spoons to invest into getting it
  • However, when something they do is challenged, such as by pointing out a mistake one has made, or a problem with their behaviour, all hell breaks loose, beacuse they see their whole sense of worth challenged, too

Note the diversity statement: it's not a problem to have one of those (and many other) tendencies, as long as one manages to keep interacting constructively with the rest of the community

Also, it is important to be aware of these patterns, to be able to compensate for one's own tendencies. What happens when an avoidant person meets a narcissistic person, and they are both unaware of the risks?


Note: there are problems with the way these resources are framed:

  • These topics are often very medicalised, and targeted at people who are victims of abuse and domestic violence.
  • I find them useful to develop regular expressions for pattern matching of behaviours, and I consider them dangerous if they are used for pattern matching of people.

Red flag / green flag


Ask for examples of red/green flags in Debian.

Green flags:

  • you heard someone say no
  • you had an argument with someone and the outcome was positive for both

Red flags:

  • you feel demeaned
  • you feel invalidated

Apologies / Dealing with issues

I don't see the usefulness of apologies that are about accepting blame, or making a person stop complaining.

I see apologies as opportunities to understand the problem I caused, help fix it, and possibly find ways of avoiding causing that problem again in the future.

A Better Way to Say Sorry lists a 4 step process, which is basically what we do when in bug reports already:

1, Try to understand and reproduce the exact problem the person had. 2. Try to find the cause of the issue. 3. Try to find a solution for the issue. 4. Verify with the reporter that the solution does indeed fix the issue.

This is just to say

My software lost
the files
that where in
your home directory

and which
you were probably
for work

Forgive me
it was so quick to write
without unit tests
and it worked so well for me

(inspired by a 1934 poem by William Carlos Williams)

Don't be afraid to fail

Don't be afraid to fail or drop the ball.

I think that anything that has a label attached of "if you don't do it, nobody will", shouldn't fall on anybody's shoulders and should be shared no matter what.

Shared or dropped.

Share the responsibility for a healthy relationship

Don't expect that the more experienced mates will take care of everything.

In a project with active people counted by the thousand, it's unlikely that harassment isn't happening. Is anyone writing anti-harassment? Do we have stats? Is having an email address and a CoC giving us a false sense of security?

When you get involved in a new community, such as Debian, find out early where, if that happens, you can find support, understanding, and help to make it stop.

If you cannot find any, or if the only thing you can find is people who say "it never happens here", consider whether you really want to be in that community.

(from http://www.enricozini.org/blog/2016/debian/you-ll-thank-me-later/)

There are some nice people in the world. I mean nice people, the sort I couldn’t describe myself as. People who are friends with everyone, who are somehow never involved in any argument, who seem content to spend their time drawing pictures of bumblebees on flowers that make everyone happy.

Those people are great to have around. You want to hold onto them as much as you can.

But people only have so much tolerance for jerkiness, and really nice people often have less tolerance than the rest of us.

The trouble with not ejecting a jerk — whether their shenanigans are deliberate or incidental — is that you allow the average jerkiness of the community to rise slightly. The higher it goes, the more likely it is that those really nice people will come around less often, or stop coming around at all. That, in turn, makes the average jerkiness rise even more, which teaches the original jerk that their behavior is acceptable and makes your community more appealing to other jerks. Meanwhile, more people at the nice end of the scale are drifting away.

(from https://eev.ee/blog/2016/07/22/on-a-technicality/)

Give people freedom

If someone tries something in Debian, try to acknowledge and accept their work.

You can give feedback on what they are doing, and try not to stand in their way, unless what they are doing is actually hurting you. In that case, try to collaborate, so that you all can get what you need.

It's ok if you don't like everything that they are doing.

I personally don't care if people tell me I'm good when I do something, I perceive it a bit like "good boy" or "good dog". I rather prefer if people show an interest, say "that looks useful" or "how does it work?" or "what do you need to deploy this?"

Acknowledge that I've done something. I don't care if it's especially liked, give me the freedom to keep doing it.

Don't give me rewards, give me space and dignity.

Rather than feeding my ego, feed by freedom, and feed my possibility to create.

Mike Gabriel: @DebConf17: Work for Debian and FLOSS I got done during DebCamp and DebConf... and Beyond...

August 13, 2017 0:44, by Planet Debian - 0no comments yet

People I Met and will Remember

  • Angela, my wife, I met daily on Jabber. Thanks for letting me go to this great DebConf17 conference and keeping our family up and running
  • Andreas asking people to either impersonate his wife or adoptive daughter for a photo shooting. You gave such a touching talk on Friday, together with Minh from Vietnam.
  • Holger for nagging us about stone age bugs in the Debian Blends package and the outdated software list in Debian Edu (Kernel 2.6.32 package are finally not mentioned anymore)
  • Vagrant, Foetini and Alkis for there efforts on LTSP and their success in Greece with bringing Debian into Greek schools
  • Tiago, Jerome and all the others from the local team, providing us with such great food and support. THANKS folks!!!
  • Enrico who showed my his 20 liner version of nodm aka lightdm-autologin-greeter (and also made me curious on staticsite)
  • Jonas Smedegaard for teaching me the solarized theme and loads of other things
  • Siri for being around and really having a stand for making Debian look more like a product
  • Dimitri John Ledkov for chiming in on Ayatana Indicators as next Indicators upstream for Ubuntu 18.04 LTS
  • Chrys for chiming on .desktop file proxying, meet you back in #arctica on Freenode
  • Sean for asking me daily, if my luggage had arrived (see below), as he shared the same fate during DebCamp
  • the owner of that nice shop where I bought loads of clothes while waiting for my luggage still stuck in Hamburg
  • Steven for looking into gcc compiler macros with me for nx-libs autotools conversion, also probably - luggage wise - the lightest traveller among us
  • Fabian for sharing is sadness and pain about the FLOSS non-situation in schools all over Quebec
  • Mario from New Zealand and Jos from the Netherlands chiming in on FLOSS and education on IRC after having watch my talk about Debian Edu / Skolelinux. Mario, we will soon ask you for opensourcing your teacher screen over WiFi solution...
  • Lior who thinks about bringing Debian Edu / Skolelinux to Israel. (That would be awesome!)
  • Rhonda for having time for my Debian Backports woes and probably having been quite forgiving ;-)
  • Bobby who is a font engineer during the week and (used to be) a cave explorer and mapper in his spare time
  • Ximin for providing deep insight in the key signing workflow and the caff approach to it
  • Daniel for sharing work experiences and nudging me to go with Remote Desktop stuff (out of pure personal interest *g*, of course, but still)
  • Tzfarir and Gunnar for a nice chat on the last night of DebConf

Topics I have worked on

  • Finding my luggage

    • After I had arrived at Montreal Airport, I found out that my luggage stayed in Hamburg
    • So the first 4.5 days, I was continuously busy with calling Lufthansa for package item tracking...
    • Go shopping twice, to update my plastic bag of fresh clothes...
  • MATE 1.18 in Debian

    • Finalize package builds of MATE 1.18 in Debian unstable (because of some GLib2.0 regression, thanks to Iain Lane for the prompt fix and upload)
  • Debian Edu

    • clear up src:package debian-edu regarding the task files related to Debian Pure Blends
    • this work is still in progress...
  • Debian Blends (esp. the blends-dev part of the blends src:package)

    • You can now have empty Depends: / Recommends: / Suggests: fields with the list of packages then starting in the next line.
    • It is now possible to have real Depends: fields in task files that become Depends: fields in debian/control. Packages targetting Depends: that are not in unstable get de-promoted to the Suggests: field in debian/control.
    • Tested with most available Debian Pure Blends meta-packages
    • I also pointed Daniel Pocock with his new GnuPG clean-room project towards Debian Pure Blends
  • Ring: A 'new' distributed video chat tool without mediating servers. Good concept, however, we could not get it to work on the DebConf campus.

  • Debian Design Team (which I am now a member of, I guess)

    • Dive into and out of the vision of a Debian Uniform set of packages, turning the collection of software in Debian into one thing.
    • Run my terminal applications now with the Base16 profile 'solarized-universal'. However, Debian Design will be much more than 16 colors in a console terminal.
    • Let's turn Debian into something like a potential product!
  • Debian Policy:

    • I even helped with a Debian Policy bug...
  • Skolab Groupware: Forking Kolab (v2) as a new project, named the Skolab Groupware. Instead of migrating my own mail server away from Kolab (v2), I chose continuing maintenance for it, at least for the core compoents:

  • nx-libs: Work on several PRs:

  • Weblate:

    • Become hosted by hosted Weblate for...
    • Ayatana Indicators
    • Arctica Project
    • Skolab Groupware

    Thanks to Michal Čihař for providing this fine translation service

Talks and BoFs

Packages Uploaded to Debian unstable

  • mate-settings-daemon
  • mate-dock-applet
  • brisk-menu
  • mate-optimus
  • caja-actions
  • mate-common
  • mate-tweak
  • plank
  • freerdp (2x)
  • freerdp2
  • gosa-plugin-mailaddress

Packages Uploaded to Debian NEW

  • python-wither
  • lightdm-autologin-greeter
  • caja-rename

I also looked into lightdm-webkit2-greeter, but upstream is in the middle of a transition from Gtk3 to Qt5, so this has been suspended for now.

Packages Uploaded to oldstable-/stable-proposed-updates or -security

  • freerdp (1.1) (actually twice, one of them a security upload)
  • gosa-plugin-mailaddress
  • mate-themes

Other Package related Stuff

  • Prepare upload of caja-admin by asking for release tags upstream
  • Talk Clint Byrums into a fresh upload of the long not touch undistract-me package
  • Breed on different desktop layouts for Debian MATE (like in Ubuntu MATE)
  • Do quite a bit of GnuPG key signing
  • Update my consent with NM to pick up my work on collab-maint request processing again

Thanks to Everyone Making This Event Possible

A big thanks to everyone who made it possible for me to attend this event!!!

Bits from Debian: DebConf17 closes in Montreal and DebConf18 dates announced

August 12, 2017 21:59, by Planet Debian - 0no comments yet

DebConf17 group photo - click to enlarge

Today, Saturday 12 August 2017, the annual Debian Developers and Contributors Conference came to a close. With over 405 people attending from all over the world, and 169 events including 89 talks, 61 discussion sessions or BoFs, 6 workshops and 13 other activities, DebConf17 has been hailed as a success.

Highlights included DebCamp with 117 participants, the Open Day,
where events of interest to a broader audience were offered, talks from invited speakers (Deb Nicholson, Matthew Garrett and Katheryn Sutter), the traditional Bits from the DPL, lightning talks and live demos and the announcement of next year's DebConf (DebConf18 in Hsinchu, Taiwan).

The full schedule has been updated every day, including 32 ad-hoc new activities, planned
by attendees during the whole conference.

For those not able to attend, talks and sessions were recorded and live streamed, and videos are being made available at the Debian meetings archive website. Many sessions also facilitated remote participation via IRC or a collaborative pad.

The DebConf17 website will remain active for archive purposes, including links to the presentations and video of each talk or event.

Next year, DebConf will be held in Hsinchu, Taiwan, from 29 July 2018 until 5 August 2018. It will be the first DebConf held in Asia. For the days before DebConf the local organisers will again set up DebCamp (21 July - 27 July), a session for some intense work on improving the distribution, and the Open Day on 28 July 2018, aimed at the general public.

DebConf is committed to a safe and welcome environment for all participants. See the DebConf Code of Conduct and the Debian Code of Conduct for more details on this.

Debian thanks the commitment of numerous sponsors to support DebConf17, particularly our Platinum Sponsors Savoir-Faire Linux, Hewlett Packard Enterprise, and Google.

About Savoir-faire Linux

Savoir-faire Linux is a Montreal-based Free/Open-Source Software company with offices in Quebec City, Toronto, Paris and Lyon. It offers Linux and Free Software integration solutions in order to provide performance, flexibility and independence for its clients. The company actively contributes to many free software projects, and provide mirrors of Debian, Ubuntu, Linux and others.

About Hewlett Packard Enterprise

Hewlett Packard Enterprise (HPE) is one of the largest computer companies in the world, providing a wide range of products and services, such as servers, storage, networking, consulting and support, software, and financial services.

HPE is also a development partner of Debian, and provides hardware for port development, Debian mirrors, and other Debian services.

About Google

Google is one of the largest technology companies in the world, providing a wide range of Internet-related services and products as online advertising technologies, search, cloud computing, software, and hardware.

Google has been supporting Debian by sponsoring DebConf since more than ten years, at gold level since DebConf12, and at platinum level for this DebConf17.

Steve Kemp: A day in the life of Steve

August 12, 2017 21:00, by Planet Debian - 0no comments yet

I used to think I was a programmer who did "sysadmin-stuff". Nowadays I interact with too many real programmers to believe that.

Or rather I can code/program/develop, but I'm not often as good as I could be. These days I'm getting more consistent with writing tests, and I like it when things are thoroughly planned and developed. But too often if I'm busy, or distracted, I think to myself "Hrm .. compiles? Probably done. Oops. Bug, you say?"

I was going to write about working with golang today. The go language is minimal and quite neat. I like the toolset:

  • go fmt
    • Making everything consistent.
  • go test

Instead I think today I'm going to write about something else. Since having a child a lot of my life is different. Routine becomes something that is essential, as is planning and scheduling.

So an average week-day goes something like this:

  • 6:00AM
    • Wake up (naturally).
  • 7:00AM
    • Wake up Oiva and play with him for 45 minutes.
  • 7:45AM
    • Prepare breakfast for my wife, and wake her up, then play with Oiva for another 15 minutes while she eats.
  • 8:00AM
    • Take tram to office.
  • 8:30AM
    • Make coffee, make a rough plan for the day.
  • 9:00AM
    • Work, until lunchtime which might be 1pm, 2pm, or even 3pm.
  • 5:00PM
    • Leave work, and take bus home.
    • Yes I go to work via tram, but come back via bus. There are reasons.
  • 5:40PM
    • Arrive home, and relax in peace for 20 minutes.
  • 6:00PM-7:00PM
    • Take Oiva for a walk, stop en route to relax in a hammock for 30 minutes reading a book.
  • 7:00-7:20PM
    • Feed Oiva his evening meal.
  • 7:30PM
    • Give Oiva his bath, then pass him over to my wife to put him to bed.
  • 7:30PM - 8:00pm
    • Relax
  • 8:00PM - 10:00PM
    • Deal with Oiva waking up, making noises, or being unsettled.
    • Try to spend quality time with my wife, watch TV, read a book, do some coding, etc.
  • 10:00PM ~ 11:30PM
    • Go to bed.

In short I'm responsible for Oiva from 6ish-8ish in the morning, then from 6PM-10PM (with a little break while he's put to bed.) There are some exceptions to this routine - for example I work from home on Monday/Friday afternoons, and Monday evenings he goes to his swimming classes. But most working-days are the same.

Weekends are a bit different. There I tend to take him 6AM-8AM, then 1PM-10PM with a few breaks for tea, and bed. At the moment we're starting to reach the peak-party time of year, which means weekends often involve negotiation(s) about which parent is having a party, and which parent is either leaving early, or not going out at all.

Today I have him all day, and it's awesome. He's just learned to say "Daddy" which makes any stress, angst or unpleasantness utterly worthwhile.

Bastian Blank: Network caps in cloud environments

August 12, 2017 21:00, by Planet Debian - 0no comments yet

Providing working network is not easy. All the cloud providers seem to know how to do that most of the time. Providing enough troughput is not easy either. Here it get's interresting as the cloud providers tackle that problem with completely different results.

There are essentially three large cloud providers. The oldest and mostly known cloud provider is Amazon Web Services (AWS). Behind that follow Microsoft with Azure and the Google Cloud Platform (GCP). Some public instances of OpenStack exist, but they simply don't count anyway. So we remain with three and they tackle this problem with widely different results.

Now, what network troughput is necessary for real world systems anyway? An old friend gives the advice: 1Gbps per Core of uncongested troughput within the complete infrastructure is the minimum. A generalization of this rule estimates around 1bps per clock cycle and core, so a 2GHz core would need 2Gbps. Do you even get a high enough network cap at your selected cloud provider to fill any of these estimates?

Our first provider, AWS, publishes a nice list of network caps for some of there instance types. The common theme in this list is: for two cores (all the *.large types) you get 500Mbps, for four cores (*.xlarge) you get 750Mbps and for eight cores (*.2xlarge) you get 1000Mbps. This is way below our estimate shown above and does not even raise linear with the number of cores. But all of this does not really matter anyway, as the performance of AWS is the worst of the three providers.

Our second provider, Azure, seems to not publish any real information about network caps at all. From my own knowledge it is 50MBps (500Mbps) per core for at least the smaller instances. At least is scales linear with instance size, but is still way below our estimates.

Our third provider, GCP, documents a simple rule for network caps: 2Gbps per core. This matches what we estimated.

Now the most important question: does this estimate really work and can we actually fill it. The answer is not easy. A slightly synthetic test of a HTTP server with cached static content showed that it can easily reach 7Gbps on a 2GHz Intel Skylake core. So yes, it gives a good estimate on what network troughput is needed for real world applications. However we still could easily file pipe that is larger by a factor of three.

Sam Hartman: Debian: a Commons of Innovation

August 12, 2017 20:10, by Planet Debian - 0no comments yet

I recently returned from Debconf. This year at Debconf, Matthew Garrett gave a talk about the next twenty years in free software. In his talk he raised concerns that Debian might not be relevant in that ecosystem and talked about some of the trends that contribute to his concerns.
I was talking to Marga after the talk and she said that Debian used to be a lot more innovative than it is today.
My initial reaction was doubt; what she said didn't feel right to me. At the time I didn't have a good answer. Since then I've been pondering the issue, and I think I have a partial answer to both Marga and Matthew and so I'll share it here.
In the beginning Debian focused on a lot of technical innovations related to bringing an operating system together. We didn't understand how to approach builds and build dependencies in a uniform manner. Producing packages in a clean environment was hard. We didn't understand what we wanted out of packages in terms of a uniform approach to configuration handling and upgrades. To a large extent we've solved those problems.
However, as the community has grown, our interests are more diverse. Our users and free software (and the operating system we build together) are what bring us together: we still have a central focus. However, no one technical project captures us all. There's still significant technical innovation in the Debian ecosystem. That innovation happens in Debian teams, companies and organizations that interact with the Debian community. We saw several talks about such innovation this year. I found the talk about ostree and flatpak interesting, especially because it focused on people in the broader Debian ecosystem valuing Debian along with some of the same technologies that Matthew is worried will undermine our relevance.
Matthew talked about how Debian ends up being a man-in-the-middle. We're between users and developers. we're between distributions and upstreams. Users are frustrated because we hold back the latest version of software they want from getting to them. Developers are frustrated because we present our users with old versions of their software configured not as they would like, combined with different dependencies than they expect.
All these weaknesses are real.
However, I think Debian-in-the-middle is our greatest strength both on the technical and social front.
I value Debian because I get a relatively uniform interface to the software I use. I can take one approach to reporting bugs whether they are upstream or Debian specific. I expect the software to behave in uniform ways with regard to things covered by policy. I know that I'm not going to have to configure multiple different versions of core dependencies; for the most part system services are shared. When Debian has value it's because our users want those things we provide. Debian has also reviewed every source file in the software we ship to understand the license and license compatibility. As a free software supporter and as someone who consumes software in commercial context, that value alone is enormous.
The world has evolved and we're facing technologies that provide different models. They've been coming for years: Python, Ruby, Java, Perl and others have been putting together their own commons of software. They have all been working to provide virtualization to isolate one program (and its dependencies) from another. Containerization takes that to the next level. Sometimes that's what our users want.
We haven't figured out what the balances are, how we fit into this new world. However, I disagree with the claim that we aren't even discussing the problem. I think we're trying a lot of things off in our own little technical groups. We're just getting to the level of critical mass of understanding where we can take advantage of Debian's modern form of innovation.
Because here's the thing. Debian's innovation now is social, not technical. Just as we're in the middle technically, we're in the middle socially. Upstreams, developers, users, derivatives, and all the other members of our community work together. we're a place where we can share technology, explore solutions, and pull apart common elements. This is the first Debconf where it felt like we'd explored some of these trends enough to start understanding how they might fit together in a whole. Seven years ago, it felt like we were busy being convinced the Java folks were wrong-headed. A couple of years later, it felt like we were starting to understand our users' desires that let to models different than packaging, but we didn't have any thoughts. At least in my part of the hallway it sounded like people were starting to think about how they might fit parts together and what the tradeoffs would be.
Yes, Matthew's talk doubtless sparked some of that. I think he gave us a well deserved and important wake-up call. However, I was excited by the discussion prior to Thursday.
What I'm taking a way is that Debian is valuable when there's a role in the middle. Both socially and technically we should capitalize on situations where something between makes things better and get out of the way where it does not.

Thorsten Glaser: [PSA] Fixing CVE-2017-12836 (Debian #871810) in GNU cvs

August 11, 2017 23:49, by Planet Debian - 0no comments yet

Considering I’ve become the de-facto upstream of cvs(GNU) even if not yet formally the de-iure upstream maintainer, fixing this bug obviously falls to me — not quite the way I had planned passing this evening after coming homw from work and a decent and, worse, very filling meal at the local Croatian restaurant. But, so’s life.

The problem here is basically that CVS invokes ssh(1) (well, rsh originally…) but doesn’t add the argument separator “--” before the (user-provided) hostname, which when starting with a hyphen-minus will be interpreted by ssh as an argument. (Apparently the other VCSes also had additional vulnerabilities such as not properly escaping semicoloi or pipes from the shell or unescaping percent-escaped fun characters, but that doesn’t affect us.)

The obvious fix and the one I implemented first is to simply add the dashes. This will also be backported to Debian {,{,old}old}stable-security.

Then I looked at other VCSes out of which only one did this, but they all added extra paranoia hostname checks (some of them passing invalid hostnames, such as those with underscores in them). OK, I thought, then also let’s add extra checks to CVS’ repository reference handling. This will end up in Debian sid and MirBSD, pending passing the regression tests of course… hah, while writing this article I had to fixup because a test failed. Anyway, it’s not strictly necessary AFAICT to fix the issue.

Update, about 2⅕ hours past midnight (the testsuite runs for several hours): of course, the “sanirt” testsuite (which itself is rather insane…) also needs adjustments, plus a bonus fix (for something that got broken when the recent allow-root-regex patch was merged and got fixed in the same go to…night).

tl;dr: a fix will end up in Debian *stable-security and can be taken out of my mail to the bugreport; another few changes for robustness are being tested and then added to both MirBSD and Debian sid. The impact is likely small, as it’s hard to get a user (if you find one, in the first place) to use a crafted CVSROOT string, which is easy to spot as well.

Michal Čihař: Weblate 2.16

August 11, 2017 17:15, by Planet Debian - 0no comments yet

Weblate 2.16 has been released today while I'm at DebConf17. There are quite some performance improvements (and more of that is scheduled for 2.17), new file formats support and various other improvements.

Full list of changes:

  • Various performance improvements.
  • Added support for nested JSON format.
  • Added support for WebExtension JSON format.
  • Fixed git exporter authentication.
  • Improved CSV import in certain situations.
  • Improved look of Other translations widget.
  • The max-length checks is now enforcing length of text in form.
  • Make the commit_pending age configurable per component.
  • Various user interface cleanups.
  • Fixed component/project/sitewide search for translations.

If you are upgrading from older version, please follow our upgrading instructions.

You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Turris, FreedomBox, Weblate itself and many other projects.

Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English SUSE Weblate

Mike Gabriel: @DebConf 2017: Ayatana Indicators

August 11, 2017 15:30, by Planet Debian - 0no comments yet

On last Tuesday, I gave a 20 min talk about Ayatana Indicators at DebConf 17 in Montreal.

Ayatana Indicators Talk

The talk had video coverage, so big thanks to the DebConf video team for making it possible to send the below video link around to people in the world:


The document of notes shown in the video is available on Debian's Infinote (Gobby) server:

$ sudo apt-get install gobby
$ sudo gobby infinote://gobby.debian.org/debconf17/talk/ayatana-indicators 

The major outcome of this talk was getting to know Dimitri John Ledkov from the Foundation Team at Canonical Ltd. We agreed on investigating the following actions, targetting the Ubuntu 18.04 LTS release and later on Debian 10 (aka buster):

Upstream Todos

  • We need to find out what indicator applets are still needed (already there: application, session, power; w-i-p: messages, not yet touch: sound, datetime, transfer). If you maintain a desktop environment and need indicator support, please contact us.
  • Rip-out liburl-dispatcher and Mir related code from all ayatana-indicator-* code projects (upstream)
  • Build-time disable phone and tablet related code (upstream). If you are from the UBPorts project and have concerns about this, please contact us.
  • Fully deprecate all Ubuntu Indicators upstream projects on Launchpad and point to Ayatana Indicators as upstream source for indicators in the Ubuntu ecosystem

Debian/Ubuntu Todos

  • Update https://wiki.debian.org/Ayatana, most important change for packagers: The team will use Git from now on, not Bazaar.
  • Get in touch with people maintaining indicator related packages (packages that have libappindicator-dev as build-dependency) to prepare for the transition from Ubuntu Indicators (unmaintained upstream, unmaintained in Debian) to Ayatana Indicators (package list, see DDPO Ayatana Developers Overview)
  • File bug reports against all packages still dependending on Ubuntu Indicators in Debian and ideally provide patches to make those packages build against Ayatana Indicators
  • Do the Ayatana Indicator transition in Debian

Please get in Touch...

As this is going to be quite an effort, esp. if we want to get this done until 18.04 LTS, let me say, that this blog post is a call for help. If you are attached to Ubuntu and have used desktops with indicator support until now, please get in touch with the Ayatana Indicators team upstream as well as downstream (Debian/Ubuntu).


  • Ayatana Indicators upstream:
    • #arctica on Freenode IRC
  • Ayatana Indicators in Debian:
  • Ubuntu Desktop Developers:
    • #ubuntu-desktop on Freenode IRC

Looking forward to meeting you online or on person and possibly working together with you on this transition project.

Mike Gabriel: @DebConf17: Story Telling about Debian Edu in Northern Germany

August 11, 2017 14:40, by Planet Debian - 0no comments yet

Last Monday, I gave a 20min talk about our little FLOSS school project "IT-Zukunft Schule" at the Debian Conference 17 in Montreal.

The talk had video coverage, so may want to peek in, if you couldn't manage to watch the life stream:


I'd like to share some major outcomes (so far) of this talk.

  1. I realized how attached I am to "IT-Zukunft Schule" and how much it means to me that our kids grow up in a world of freedom and choice. Also and esp. when it comes to choosing your daily communication tools and computer working environment
  2. I met Foteini Tsiami and Alkis Georgopoulos from Greece. They work on LTSP and have deployed 1000+ schools in Greece with LTSP + Debian GNU/Linux + MATE Desktop Environment
  3. I met Vagrant Cascadian who is the maintainer of LTSP in Debian and also a major LTSP upstream contributor
  4. I received a lot of fine feedback that was very encouraging to go on with our local work in Schleswig-Holstein

If you have some more time for watching DebConf talks on video, I dearly recommend the talk given by Alkis and Foteini on their Greek FLOSS success story. If you don't have that much time, please skip through the video until you are at 26:15 and enjoy the map that shows how much Debian + LTSP has spread over all of Greece.


Unfortunately, the schools in Greece are so much smaller than schools in Germany. Most schools there have between 50 and 300 students. So at the Greek schools, it is possible to have a teacher machine being the server for one computer lab. This teacher / server machine provides the infrastructure for a room full of LTSP fat clients (no hard drive inside) and that's it.

For German schools, unfortunately, we need a larger scale setup. German schools often have 800+ students and network services need to be spread over more than one server machine. So, the current approach with one server running LDAP, Kerberos etc. is quite appropriate, but also extendible, possibly on municipality level or on county level.

We (from IT-Zukunft Schule) are quite positive that there will be opportunities for introducing FLOSS approaches more on the county level in Schleswig-Holstein in the near future. So stay tuned...

Lucas Nussbaum: systemd services, and queue management?

August 11, 2017 12:40, by Planet Debian - 0no comments yet

I’ve been increasingly using systemd timers as a replacement for cron jobs. The fact that you get free logging is great, and also the fact that you don’t have to care about multiple instances running simultaneously.

However, sometimes I would be interested in more complex scenarios, such as:

  • I’d like to trigger a full run of the service unit: if the service is not running, it should be started immediately. If it’s currently running, it should be started again when it terminates.
  • Same as the above, but with queue coalescing: If I do the above multiple times in a row, I only want the guarantee that there’s one full run of the service after the last time I triggered it (typical scenario: each run processes all pending events, so there’s no point in running multiple times).

Is this doable with systemd? If not, how do people do that outside of systemd?