Self signed SSL certificates are nice, but only provide encryption of retrieved data. Nobody knows who is really sending the data. If one buys an SSL certificate for a website, the browser doesn t complain as much as with a self signed certificate. But can you really trust the other side? Almost every commercial CA has some kind of fast validation or domain validation, issued in minutes , which is done by email or phone. So if required, within minutes everybody might become you. Even with putting money on the table your users can not be sure whether this server really belongs to the right guy. Well, why wasting time and money? Just create your own Root CA and tell users that they need to add something in order to avoid some error messages. In Debian we basically have five packages who claim to be able to manage some kind of CA.

• easy-rsa
• FreeIPA
• gnomint
• tinyCA
• xca

easy-rsa is mainly needed to manage certificates used by openVPN. Within this use case it works like a charm, but I don t want to manage a more complex CA with it. gnomint is dead upstream and only uses SHA1 as signature algorithm. This will cause lots of problems as Mircrosoft and Google want to deprecate SHA1 in their products by 2017. Besides, this package is already orphaned and maybe it can disappear now. tinyCA uses more signature algorithms, unfortunately SHA1 seems to be the best it can. There are some patches to support up to SHA512, but they don t work for all parts of the software yet. For example Sub-CAs still use SHA1 despite of choosing something different in the GUI. So nice, but not (yet) usable in Jessie. FreeIPA seems to be great, but didn t make it into Jessie in time. Unfortunately the Release Team has reasons to not unblock it. So nice, but not usable in Jessie. xca is based on QT4. As announced in the 15th DPN of 2014 the deprecated QT4 will be removed from Debian Stretch (= Jessie+1). Apart from this, the software meets all my requirements.

If your request doesn t appear on the list, probably the diff was too big There s a size limit for mails to debian-release@lists.debian.org, and in general that s how we read unblock requests. If your mail doesn t appear on the list, but you do get a bug number back, your mail is likely too large.. In this case, that s probably a sign that we won t accept your request without exceptional circumstances. Making so many changes in a package is almost certainly not appropriate for this phase of the cycle. Do use filterdiff to remove automatically-generated files from your diff before sending it, which increases the chances of acceptance. Do follow up to the bug if it doesn t appear on the list; send a short message explaining that happened and why your giant diff should be considered. Don t be surprised if thousands and thousands of lines changed are rejected.

---

Getting things into Jessie (#2) is a post from: jwiltshire.org.uk Flattr

Sometimes I look out the window and can t help but feel this weather is deep. Deep with meaning, with import. Almost as if the weather is confident of itself, and is challenging me to find some meaning within it. This weekend brought the first blast of winter to the plains of Kansas. Saturday was chilly and windy, and overnight a little snow fell. Just enough to cover up the ground and let the tops of the blades of grass poke through. Just enough to make the landscape look totally different, without completely hiding what lies beneath. Laura and I stood silently at the window for a few minutes this morning, gazing out over the untouched snow, extending out as far as we can see. Yesterday, I spent some time with my great uncle and aunt. My great uncle isn t doing so well. He s been battling cancer and other health issues for some time, and can t get out of the house very well. We talked for an hour and a half about news of the family, struggles in life now and in the past, and joys. There were times when all three of us had tears in our eyes, and times when all of us were laughing so loudly. My great uncle managed to stand up twice while I was there this took quite some effort once to give me a huge hug when I arrived, and another to give me an even bigger hug when I left. He has always been a person to give the most loving hugs. He hadn t been able to taste food for awhile, due to treatment for cancer. When I realized he could taste again, I asked, When should I bring you some borscht? He looked surprised, then got a huge grin, glanced at his watch, and said, Can you be back by 3:00? His brother, my grandpa, was known for his beef borscht. I also found out my great uncle s favorite kind of bread, and thought that maybe I would do some cooking for him sometime soon. Today on my way home from church, I did some shopping. I picked up the ingredients for borscht and for bread. I came home, said hi to the cats that showed up to greet me, and went inside. I turned on the radio Prairie Home Companion was on and started cooking. It takes a long time to prepare what I was working on I spent a solid two hours in the kitchen. As I was chopping up a head of cabbage, I remembered coming to what is now my house as a child, when my grandpa lived here. I remembered his borscht, zwiebach, monster cookies; his dusty but warm wood stove; his closet with toys in it. I remembered two years ago, having nearly 20 Goerzens here for Christmas, hosted by the boys and me, and the 3 gallons of borscht I made for the occasion. I poured in some tomato sauce, added some water. The radio was talking about being kind to people, remembering that others don t always have the advantages we do. Garrison Keillor s fictional boy in a small town, when asked what advantages he had, mentioned belonging. Yes, that is an advantage. We all deal with death, our own and that of loved ones, but I am so blessed by belonging to a loving family, two loving churches, a wonderful community. Out came three pounds of stew beef. Chop, chop, slice, plunk into the cast iron Dutch oven. It s my borscht pot. It looks as if it would be more at home over a campfire than a stovetop, but it works anywhere. Outside, the sun came up. The snow melts a little, and the cats start running around even though it s still below freezing. They look like they re having fun playing. I m chopping up parsley and an onion, then wrapping them up in a cheesecloth to make the spice ball for the borscht. I add the basil and dill, some salt, and plonk them in, too. My 6-quart pot is nearly overflowing as I carefully stir the hearty stew. On the radio, a woman who plays piano in a hospital and had dreamed of being on that particular radio program for 13 years finally was. She played with passion and delight I could hear through the radio. Then it s time to make bread. I pour in some warm water, add some brown sugar, and my thoughts turn to Home On The Range. I am reminded of this verse:

How often at night when the heavens are bright
With the light from the glittering stars
Have I stood here amazed and asked as I gazed
If their glory exceeds that of ours.

There s something about a beautiful landscape out the window to remind a person of all the blessings in life. This has been a quite busy weekend actually, a busy month but despite the fact I have a relative that is sick in the midst of it all, I am so blessed in so many ways. I finish off the bread, adding some yeast, and I remember my great uncle thanking me so much for visiting him yesterday. He commented that a lot of younger people have no use for visiting an old geezer like me. I told him, I ve never been like that. I am so glad I could come and visit you today. The best gifts are those that give in both directions, and this surely is that. Then I clean up the kitchen. I wipe down the counters from all the bits of cabbage that went flying. I put away all the herbs and spices I used, and finally go to sit down and reflect. From the kitchen, the smells of borscht and bread start to seep out, sweeping up the rest of the house. It takes at least 4 hours for the borscht to cook, and several hours for the bread, so this will be an afternoon of waiting with delicious smells. Soon my family will be home from all their activities of the day, and I will be able to greet them with a warm house and the same smells I stepped into when I was a boy. I remember this other verse from Home On the Range:

Where the air is so pure, the zephyrs so free,
The breezes so balmy and light,
That I would not exchange my home on the range
For all of the cities so bright.

Today s breeze is an icy blast from the north maybe not balmy in the conventional sense. But it is the breeze of home, the breeze of belonging. Even today, as I gaze out at the frozen landscape, I realize how balmy it really is, for I know I wouldn t exchange my life on the range for anything.

I was not much at home during the last two weeks, so not much to report about RC bug activities. some general observations:

1. the RC bug count is still relatively low, even after lucas' archive rebuild.
2. the release team is extremely fast in handling unblock request - kudos! pro tip: file them quickly after uploading, or some thing,one else might be faster :)

my small contributions:

• #765327 libnet-dns-perl: "lintian fails if the machine has a link-local IPv6 nameserver configured"
  discuss possible fix with upstream (pkg-perl)
• #768683 src:libmoosex-storage-perl: "libmoosex-storage-perl: missing runtime dependencies cause (build) failures in other packages"
  move packages from Recommends to Depends (pkg-perl)
• #768692 src:libaudio-mpd-perl: "libaudio-mpd-perl: FTBFS in jessie: Failed test '10 seconds worth of music in the db': got: '9'"
  add patch from Simon McVittie (pkg-perl)
• #768712 src:libpoe-component-client-mpd-perl: "libpoe-component-client-mpd-perl: FTBFS in jessie: Failed test '10 seconds worth of music in the db': got: '9'"
  add patch from Simon McVittie (pkg-perl)
• #769003 libgluegen2-build-java: "libjogl2-java: FTBFS on arm64, ppc64el, s390x"
  add patch from Colin Watson (pkg-java)

Big changes are always a complicated thing to get done and can be the harder the bigger or more diverse an organization is it is taking place in. Transparency Ideally every change is well communicated early and openly. Leaving people in the dark about what will change and when means people have much less time to feeling comfortable about it or arranging with it mentally. Especially bad can be extending the change later or or shortening transition periods. Letting people think they have some time to transition only to force them to rush later will remove any credibility you have and severely reduce their ability to believe you are not crossing them. Making a new way optional is a great way to create security (see below), but making that obligatory before the change even arrives as optional with them will not make them very willing to embrace change. Take responsibility Every transformation means costs. Even if some change did only improve and did not make anything worse once implemented (the ideal change you will never meet in reality), the deployment of the change still costs: processes have adapted to it, people have to relearn how to do things, how to detect if something goes wrong, how to fix it, documentation has to be adopted and and and. Even as the change causes more good than costs in the whole organization (let's hope it does, I hope you wouldn't try to do something if the total benefit is negative), the benefits and thus the benefit to cost ratio will differ for the different parts of your organization or the different people within it. It's hardly avoidable that for some people there will not be much benefit, much less perceived benefit compared to the costs they have to burden for it. Those are the people whose good will you want to fight for, not the people you want to fight against. They have to pay with their labor/resources and thus their good will for your benefit the overall benefit. This is much easier if you acknowledge that fact. If you blame them for having the costs, claim their situation does not even exist or even ridicule them for not embracing change you only prepare yourself for frustration. You might be able to persuade yourself that everyone that is not willing to invest in the change is just acting out of malevolent self-interest. But you will hardly be able to persuade people that it is evil to not help your cause if you treat them as enemies. And once you ignored or played down costs that later actually happen, your credibility in being able to see the big picture will simply cease to exist at all for the next change. Allow different metrics People have different opinions about priorities, about what is important, about how much something costs and even about what is a problem. If you want to persuade them, try to take that into account. If you do not understand why something is a reason, it might be because the given point is stupid. But it might also be that you miss something. And often there is simple a different valuation of what is important, what the costs are and what are problems. If you want to persuade people, it is worth to try to understand those. If all you want to do is persuade some leader or some majority then ridiculing their concerns might get you somewhere. But how do you want to win people over if you do not even appear to understand their problems. Why should people trust you that their costs will be worth the overall benefits if you tell them the costs that they clearly see do not exist? How credible is referring to the bigger picture if the part of the picture they can see does not match what you say the bigger picture looks like? Don't get trolled and don't troll There will always be people that might be unreasonable or even try to provoke you. Don't allow being provoked. Remember that for successful changes you need to win broad support. Feeling personally attacked or feeling presented a large amount of pointless arguments easily results in not bringing proper responses or actually looking at arguments. If someone is only trolling and purely malevolent, they will tease you best if they bring actual concerns of people in a way you likely degrade your yourself and your point in answering. Becoming impertinent with the troll is like attacking the annoying little goblin hiding next to the city guards with area damage. When not being able to persuade people, it is also far to easy to consider them in bad faith and/or attacking them personally. This can only escalate even more. Worst case you frustrate someone in good faith. In most cases you poison the discussion so much that people actually in good faith will no longer contribute the discussion. It might be rewarding short term because after some escalation only obviously unreasonable people will talk against you, but it makes it much harder to find solutions together that could benefit anyone and almost impossible to persuade those that simply left the discussion. Give security Last but not least, remember that humans are quite risk-averse. In general they might invest in (even small) chances to win, but go a long way to avoid risks. Thus an important part of enabling change is to reduce risks, real and perceived ones and give people a feeling of security. In the end, almost every measure boils down to that: You give people security by giving them the feeling that the whole picture is considered in decisions (by bringing them early into the process, by making sure their concerns are understood and part of the global profit/cost calculation and making sure their experiences with the change are part of the evaluation). You give people security by allowing them to predict and control things (by transparency about plans, how far the change will go and guaranteed transitions periods, by giving them enough time so they can actually plan and do the transition). You give people security by avoiding early points of no return (by having wide enough tests, rollback scenarios,...). You give people security by not letting them alone (by having good documentation, availability of training, ...). Especially side-by-side availability of old and new is an extremely powerful tool, as it fits all of the above: It allows people to actually test it (and not some little prototype mostly but not quite totally unrelated to reality) so their feedback can be heard. It makes it more predictable as all the new ways can be tried before the old ones no longer work. It is the ultimate role-back scenario (just switch off the new). And allows for learning the new before losing the old. Of course giving the people a feeling of security needs resources. But it is a very powerful way to get people to embrace the chance. Also in my experience people only fearing for themselves will usually mostly be passive by not pushing forward and trying to avoid or escape the changes. (After all, working against something costs energy, so purely egoistic behavior is quite limiting in that regard). Most people actively pushing back do it because they fear for something larger than only them. And any measure to making them fear less that you ruin the overall organization, not only avoids unnecessary hurdles rolling out the change but also has some small chance to actually avoid running into disaster with closed eyes.

I have recently moved to Lausanne, Switzerland. Broadband Internet access is not as cheap as in France. Free, a French ISP, is providing an FTTH access with a bandwith of 1 Gbps¹ for about 38 (including TV and phone service), Swisscom is providing roughly the same service for about 200 ². Swisscom fiber access was available for my appartment and I chose the 40 Mbps contract without phone service for about 80 . Like many ISP, Swisscom provides an Internet box with an additional box for TV. I didn t unpack the TV box as I have no use for it. The Internet box comes with some nice features like the ability to setup firewall rules, a guest wireless access and some file sharing possibilities. No shell access! I have bought a small PC to act as router and replace the Internet box. I have loaded the upcoming Debian Jessie on it. You can find the whole software configuration in a GitHub repository. This blog post only covers the Swisscom-specific setup (and QoS). Have a look at those two blog posts for related topics:

• Staging a Netfilter ruleset in a network namespace
• Intel Wireless 7260 as an access point

Ethernet The Internet box is packed with a Siligence-branded 1000BX SFP³. This SFP receives and transmits data on the same fiber using a different wavelength for each direction. Instead of using a network card with an SFP port, I bought a Netgear GS110TP which comes with 8 gigabit copper ports and 2 fiber SFP ports. It is a cheap switch bundled with many interesting features like VLAN and LLDP. It works fine if you don t expect too much from it.

IPv4 IPv4 connectivity is provided over VLAN 10. A DHCP client is mandatory. Moreover, the DHCP vendor class identifier option (option 60) needs to be advertised. This can be done by adding the following line to /etc/dhcp/dhclient.conf when using the ISC DHCP client:

send vendor-class-identifier "100008,0001,,Debian";

The first two numbers are here to identify the service you are requesting. I suppose this can be read as requesting the Swisscom residential access service. You can put whatever you want after that. Once you get a lease, you need to use a browser to identify yourself to Swisscom on the first use.

IPv6 Swisscom provides IPv6 access through the 6rd protocol. This is a tunneling mechanism to facilitate IPv6 deployment accross an IPv4 infrastructure. This kind of tunnel is natively supported by Linux since kernel version 2.6.33. To setup IPv6, you need the base IPv6 prefix and the 6rd gateway. Some ISP are providing those values through DHCP (option 212) but this is not the case for Swisscom. The gateway is 6rd.swisscom.com and the prefix is 2a02:1200::/28. After appending the IPv4 address to the prefix, you still get 4 bits for internal subnets. Swisscom doesn t provide a fixed IPv4 address. Therefore, it is not possible to precompute the IPv6 prefix. When installed as a DHCP hook (in /etc/dhcp/dhclient-exit-hooks.d/6rd), the following script configures the tunnel:

sixrd_iface=internet6
sixrd_mtu=1472                  # This is 1500 - 20 - 8 (PPPoE header)
sixrd_ttl=64
sixrd_prefix=2a02:1200::/28     # No way to guess, just have to know it.
sixrd_br=193.5.29.1             # That's "6rd.swisscom.com"
sixrd_down()  
    ip tunnel del $ sixrd_iface    true
 
sixrd_up()  
    ipv4=$ new_ip_address:-$old_ip_address 
    sixrd_subnet=$(ruby <<EOF
require 'ipaddr'
prefix = IPAddr.new "$ sixrd_prefix ", Socket::AF_INET6
prefixlen = $ sixrd_prefix#*/ 
ipv4 = IPAddr.new "$ ipv4 ", Socket::AF_INET
ipv6 = IPAddr.new (prefix.to_i + (ipv4.to_i << (64 + 32 - prefixlen))), Socket::AF_INET6
puts ipv6
EOF
)
    # Let's configure the tunnel
    ip tunnel add $ sixrd_iface  mode sit local $ipv4 ttl $sixrd_ttl
    ip tunnel 6rd dev $ sixrd_iface  6rd-prefix $ sixrd_prefix 
    ip addr add $ sixrd_subnet 1/64 dev $ sixrd_iface 
    ip link set mtu $ sixrd_mtu  dev $ sixrd_iface 
    ip link set $ sixrd_iface  up
    ip route add default via ::$ sixrd_br  dev $ sixrd_iface 
 
case $reason in
    BOUND REBOOT)
        sixrd_down
        sixrd_up
        ;;
    RENEW REBIND)
        if [ "$new_ip_address" != "$old_ip_address" ]; then
            sixrd_down
            sixrd_up
        fi
        ;;
    STOP EXPIRE FAIL RELEASE)
        sixrd_down
        ;;
esac

The computation of the IPv6 prefix is offloaded to Ruby instead of trying to use the shell for that. Even if the ipaddr module is pretty basic , it suits the job. Swisscom is using the same MTU for all clients. Because some of them are using PPPoE, the MTU is 1472 instead of 1480. You can easily check your MTU with this handy online MTU test tool. It is not uncommon that PMTUD is broken on some parts of the Internet. While not ideal, setting up TCP MSS will alievate any problem you may run into with a MTU less than 1500:

ip6tables -t mangle -A POSTROUTING -o internet6 \
          -p tcp --tcp-flags SYN,RST SYN \
          -j TCPMSS --clamp-mss-to-pmtu

QoS UPDATED: Unfortunately, this section is incorrect, including its premise. Have a look at Dave Taht comment for more details. Once upon a time, QoS was a tacky subject. The Wonder Shaper was a common way to get a somewhat working setup. Nowadays, thanks to the work of the Bufferbloat project, there are two simple steps to get something quite good:

1. Reduce the queue of your devices to something like 32 packets. This helps TCP to detect congestion and act accordingly while still being able to saturate a gigabit link.

   ip link set txqueuelen 32 dev lan
   ip link set txqueuelen 32 dev internet
   ip link set txqueuelen 32 dev wlan
   

2. Change the root qdisc to fq_codel. A qdisc receives packets to be sent from the kernel and decide how packets are handled to the network card. Packets can be dropped, reordered or rate-limited. fq_codel is a queuing discipline combining fair queuing and controlled delay. Fair queuing means that all flows get an equal chance to be served. Another way to tell it is that a high-bandwidth flow won t starve the queue. Controlled delay means that the queue size will be limited to ensure the latency stays low. This is achieved by dropping packets more aggressively when the queue grows.

   tc qdisc replace dev lan root fq_codel
   tc qdisc replace dev internet root fq_codel
   tc qdisc replace dev wlan root fq_codel
   

---

1. Maximum download speed is 1 Gbps, while maximum upload speed is 200 Mbps.
2. This is the standard Vivo XL package rated at CHF 169. plus the 1 Gbps option at CHF 80. .
3. There are two references on it: SGA 441SFP0-1Gb and OST-1000BX-S34-10DI. It transmits to the 1310 nm wave length and receives on the 1490 nm one.

Some of you may already be aware of the gift tag which has been used for a while to indicate bugs which are suitable for new contributors to use as an entry point to working on specific packages. Unfortunately, some of us (including me!) were unaware that this tag even existed. Luckily, Lucas Nussbaum clued me in to the existence of this tag, and after a brief bike-shed-naming thread, and some voting using pocket_devotee we decided to name the new tag newcomer, and I have now added this tag to the BTS documentation, and tagged all of the bugs which were user tagged "gift" with this tag. If you have bugs in your package which you think are ideal for new contributors to Debian (or your package) to fix, please tag them newcomer. If you're getting started in Debian, and working on bugs to fix, please search for the newcomer tag, grab the helm, and contribute to Debian.

New set of metapackagesThe version number of debian-med metapackages was bumped to 1.99 as a signal that we plan to release version 2.0 with Jessie. As usual the metapackages will be recreated shortly before the final release to include potential changes in the package pool. Feel free to install the metapackages med-* with the package installer of your choice. As always you can have a look at the packages in our focus by visiting our tasks pages. Please note that there may be new packages that aren t ready for release and that won t be installed by using the current metapackages. This is because we don t stop packaging software when the current testing is in freeze. Some support for Hospital Information SystemsThis release contains, for the first time some support for Hospital Information Systems (HIS) with the dependency fis-gtm of the med-his metapackage. This was made possible due to the work of Luis Ibanez (at kitware at the time when working on the packaging) and Amul Shah (fisglobal). Thanks to a fruitful cooperation between upstream FIS and Debian the build system of fis-gtm was adapted to enable an easier packaging. The availability of fis-gtm will simplify running Vista-foia on Debian systems and we are finally working on packaging Vista as well to make Debian fit for running inside hospitals. There was some interesting work done by Emilien Klein who was working hard to get GNUHealthpackaged. Emilien has given a detailed explanation on the Debian Med mailing list giving reasons why he removed the existing packages from the Debian package pool again. While this is a shame for GNUHealth users there might be an opportunity to revive this effort if there was better coordination between upstream and Tryton (which is the framework GNUHealth is based upon). In any case the packaging code in SVN as a useful resource to base private packages on. Feel free to contact us via the Debian Med mailing list if you consider creating GNUHealth Debian packages. Packages moved from non-free to mainThe Debian Med team worked hard to finally enable DFSG free licenses for PHYLIPand other package based on this tool. PHYLIP is well known in bioinformatics and actually one of the first packages in this field inside Debian (oldest changelog entry 28 Aug 1998). Since then it was considered non-free because its use was restricted to scientific / non-commercial use and also has the condition that you need to pay a fee to the University of Washington if you intend to use it commercially. Since Debian Med was started we were in continuous discussion with the author Joe Felsenstein. We even started an online petition to show how large the interest in a DFSG free PHYLIP might be. As a side note: This petition was *not* presented to the authors since they happily decided to move to a free license because of previous discussion and since they realised that the money they "gained" over they years was only minimal. The petition is mentioned here to demonstrate that it is possible to gather support to see positive changes implemented that benefit all users and that this approach can be used for similar cases. So finally PHYLIP was released in September under a BSD-2-clause license and in turn SeaView (a similarly famous program and also long term non-free citizen) depending on PHYLIP code was freed as well. There are several other tools like python-biopython and python-cogent which are calling PHYLIP if it exists. So not only is PHYLIP freed we can now stop removing those parts of the test suites of these other tools that are using PHYLIP. Thanks to all who participated in freeing PHYLIP specifically its author Joe Felsenstein. Autopkgtest in Debian Med packagesWe tried hard to add autopkgtests to all packages where some upstream test suite exists and we also tried to create some tests on our own. Since we consider testing of scientific software a very important feature this work was highly focused on for the Jessie release. When doing so we were able to drastically enhance the reliability of packages and found new formerly hidden dependency relations. Perhaps the hardest work was to run the full test suite of python-biopython which also has uncovered some hidden bugs in the upstream code on architectures that are not so frequently used in the field of bioinformatics. This was made possible by the very good support of upstream who were very helpful in solving the issues we reported. However, we are not at 100% coverage of autopkgtest and we will keep on working on our packages in the next release cycle for Jessie+1. General quality assuranceA general inspection of all Debian Med packages was done to check all packages which were uploaded before the Wheezy release and never touched since then. Those packages where checked for changed upstream locations which might have been hidden from uscan and in some cases new upstream releases were spotted by doing this investigation. Other old packages were re-uploaded conforming to current policy and packaging tools also polishing lintian issues. Publication with Debian Med involvementThe Debian Med team is involved in a paper which is in BioMed Central (in press). The title will be "Community-driven development for computational biology at Sprints, Hackathons and Codefests" Updated team metricsThe team metrics graphs on the Debian Med Blend entry page were updated. At the bottom you will find a 3D Bar chart of dependencies of selected metapackages over different versions. It shows our continuous work in several fields. Thanks to all Debian Med team members for their rigorous work on our common goal to make Debian the best operating system for medicine and biology. Please note that VCS stat calculation is currently broken and does not reflect the latest commits this year. Blends installable via d-i?In bug #758116 it is requested to list all Blends and thus also Debian Med in the initial tasksel selection. This would solve a long term open issue which was addessed more than eleven years ago (in #186085) in a more general and better way. This would add a frequently requested feature by our users who always wonder how to install Debian Med. While there is no final decision on bug #758116 and we are quite late with the request to get this implemented in Jessie feel free to contribute ideas so that this selection of Blends can be done in the best possible manner. Debian Med Bug Squashing Advent Calendar 2014The Debian Med team will again do the Bug Squashing Advent Calendar. Feel free to join us in our bug squashing effort where we close bugs while other people are opening doors. :-)

DebConf15 will take place in Heidelberg, Germany in August 2015. We strive to provide an intense working environment and enable good progress for Debian and for Free Software in general. We extend an invitation to everyone to join us and to support this event. As a volunteer-run non-profit conference, we depend on our sponsors. Nine companies have already committed to sponsor DebConf15! Let's introduce them: Our first Gold sponsor is credativ, a service-oriented company focusing on open-source software, and also a Debian development partner. Our second Gold sponsor is sipgate, a Voice over IP service provider based in Germany that also operates in the United Kingdom (sipgate site in English). Google (the search engine and advertising company), Fairsight Security, Inc. (developers of real-time passive DNS solutions), Martin Alfke / Buero 2.0 (Linux & UNIX Consultant and Trainer, LPIC-2/Puppet Certified Professional) and Ubuntu (the OS supported by Canonical) are our three Silver sponsors. And last but not least, Logilab, Netways and Hetzner have agreed to support us as Bronze-level. Become a sponsor too! Would you like to become a sponsor? Do you know of or work in a company or organization that may consider sponsorship? Please have a look at our sponsorship brochure (also available in German), in which we outline all the details and describe the sponsor benefits. For instance, sponsors have the option to reach out to Debian contributors, derivative developers, upstream authors and other community members during a Job Fair and through postings on our job wall, and to show-case their Free Software involvement by staffing a booth on the Open Weekend. In addition, sponsors are able to distribute marketing materials in the attendee bags. And it goes without saying that we honour your sponsorship with visibility of your logo in the conference's videos, on our website, on printed materials, and banners. The final report of DebConf14 is also available, illustrating the broad spectrum, quality, and enthusiasm of the community at work, and providing detailed information about the different outcomes that last conference brought up (talks, participants, social events, impact in the Debian project and the free software scene, and much more). For further details, feel free to contact us through sponsors@debconf.org, and visit the DebConf15 website at http://debconf15.debconf.org.

This is a reply to Josselin Mouette's blog article About choice, since his blog does not seem to accept comments . Please note that this is not meant to be systemd-bashing, just a criticism base one a counter-example refutation of Josselin's implication that there is no use case better covered by SysV init: this is false, as there is at least one. And yes, there are probably many cases better covered by systemd, I am making no claims about that.A use case better covered by SysV init: encrypted block devices So, waiting for a use case better covered by SysV init? Rejoice, you will not die waiting, here is one: encrypted block devices. That case works just fine with SysV init, without any specific configuration, whereas systemd just sucks at it. There exist a way to make it work , but:

• if systemd requires specific configuration to handle such a case, whereas SysV init does not, that means this case is better covered by SysV init;
• that work around does not actually work.

If you know any better, I would be glad to try it. Believe me, I like the basic principles of systemd and I would be glad to have it working correctly on my system. Notes

1. Well, it does accept comments, but marks them as span and does not show them, which is roughly equivalent.
2. Installing an additional piece of software, Plymouth, is supposed to make systemd work correctly with encrypted block devices. Yes, this is additional configuration, as that piece of software does not come when you install systemd, and it is not even suggested so a regular user cannot guess it.
3. Though I must say I hate the way it is pushed into the GNU/Linux desktop systems.

My desk today looks like this: Yep, that s a computer. Motherboard to the right, floppy drives and CD drive stacked on top of the power supply, hard drive to the left. And it s an OLD computer. (I had forgotten just how loud these old power supplies are; wow.) The point of this exercise is to read data off the floppies that I have made starting nearly 30 years ago now (wow). Many were made with DOS, some were made on a TRS-80 Color Computer II (aka CoCo 2). There are 5.25 disks, 3.25 disks, and all sorts of formats. Most are DOS, but the TRS-80 ones use a different physical format. Some of the data was written by Central Point Backup (from PC Tools), which squeezed more data on the disk by adding an extra sector or something, if my vague memory is working. Reading these disks requires low-level playing with controller timing, and sometimes the original software to extract the data. It doesn t necessarily work under Linux, and certainly doesn t work with USB floppies or under emulation. Hence this system. It s a bridge. Old enough to run DOS, new enough to use an IDE drive. I can then hook up the IDE drive to a IDE-to-USB converter and copy the data off it onto my Linux system. But this was tricky. I started the project a few years ago, but life got in the way. Getting back to it now, with the same motherboard and drive, but I just couldn t get it to boot. I eventually began to suspect some disk geometry settings, and with some detective work from fdisk in Linux plus some research into old BIOS disk size limitations, discovered the problem was a 2GB limit. Through some educated trial and error, I programmed the BOIS with a number of cylinders that worked, set it to LBA mode, and finally my 3-year-old DOS 6.2 installation booted. I had also forgotten how finicky things were back then. Pop a floppy from a Debian install set into the drive, type dir b:, and the system hangs. I guess there was a reason the reset button was prominent on the front of the computer back then

It s finally become properly autumnal, in the real world and in Debian. One week ago, I announced (on behalf of the whole release team) that Debian 8 Jessie had successfully frozen on time. At 18:00 that evening we had 310 release critical bugs that is, the number that we must reduce to 0 before the release is ready. How does that number look now? Well, there are now 315 bugs affecting Jessie, at various stages of progression. That sounds like it s going in the wrong direction, but considering that over a hundred new bugs were filed just 8 hours after the freeze announcement, things are actually looking pretty good. Out of those 315 bugs, 91 have been fixed and the packages affected have already been unblocked by the release team. The fixed packages will migrate to Jessie in the next few days, if they continue to be bug-free. Thirty-four bugs are apparently fixed in unstable but are not cleared for migration yet. That means that the release team has not spotted the fix, or nobody has told us, or the fixed package is unsuitable for some other reason (like unrelated changes in the same upload). You can help by trying to find out which reason applies, and talking to us about it. Most likely nobody has asked us to unblock it yet. Speaking of unblocks, we currently have twenty-four requests that need to be looked at, and a further 20 which are awaiting more information from the maintainer. We already investigated and resolved 260 requests. Our response rate is currently pretty good, but it s unclear whether we can sustain it indefinitely. We all have day jobs, for example. One way you could help is to review the list of unchecked unblocks and gather up missing information, or look at the ones tagged moreinfo and see whether that s still the case (maybe the maintainer replied, but forgot to remove the tag). If you re confident, you might even try triaging some of the obvious requests and give some feedback to the maintainer, though the final decision will be made by a release team member. After all, the quicker this goes the sooner we can release and thaw up unstable again.

---

Footnote: the method used to determine RC bug counts last week and this week differ, and therefore so could the margin for error. Surprisingly enough, counting bugs is not an exact science. I m confident these numbers are close enough for broad comparison, even if they re out by one or two.

---

A chilly week is a post from: jwiltshire.org.uk Flattr

Like last month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In October 2014, we affected 13.75h works hours to 3 contributors:

• Thorsten Alteholz
• Rapha l Hertzog worked only 10 hours. The remaining hours will be done over November.
• Holger Levsen did nothing (for unexpected personal reasons), he will catch up in November.

Obviously, only the hours done have been paid. Should the backlog grow further, we will seek for more paid contributors (to share the workload) and to make it easier to redispatch work hours once a contributor knows that he won t be able to handle the hours that were affected to him/her. Evolution of the situation Compared to last month, we gained two new sponsors (Daevel and FOSSter, thanks to them!) and we have now 45.5 hours of paid LTS work to spend each month. That s great but we are still far from our minimal goal of funding the equivalent of a half-time position. In terms of security updates waiting to be handled, the situation is a bit worse than last month: while the dla-needed.txt file only lists 33 packages awaiting an update (6 less than last month), the list of open vulnerabilities in Squeeze shows about 60 affected packages in total. This differences has two explanations: CVE triaging for squeeze has not been done in the last days, and the POODLE issue(s) with SSLv3 affects a very large number of packages where it s not always clear what the proper action is. In any case, it s never too late to join the growing list of sponsors and help us do a better job, please check with your company managers. If not possible for this year, consider including it in the budget for next year. Thanks to our sponsors Let me thank our main sponsors:

• Gold sponsors:
• The Positive Internet
• Silver sponsors:
• AD&D David Ayers IntarS Austria
• Blablacar
• Domeneshop AS
• Evolix
• Trollweb Solutions
• Universit Lille 3
• Bronze sponsors:
• Daevel SARL
• FOSSter
• Freeside Internet Service
• Intevation GmbH
• Linuxhotel GmbH
• MyTux
• Nantes M tropole
• Offensive Security
• Seznam.cz, a.s.

No comment Liked this article? Click here. My blog is Flattr-enabled.

I had prepared a long and somewhat emotional blog post called "On unintended consequences" to write a rather sad bit of news off of my heart. While I believe the points raised were logical, courteous, and overall positive, I decided to do something different and replace sad things with happy things. So anyway, for 3-4 people you will need:

• The largest, widest cooking pot you can find (you want surface to let more water evaporate)
• 500g noodles, preferably Bavette
• 300g cherry tomatoes
• ~150g sundried tomatoes
• ~150g grilled peppers
• a handful of olives
• two medium-sized red onions
• as much garlic as is socially acceptable in your group
• one or two handful of fresh basil leaves
• large gulp of olive oil
• ~100g fresh-ground Parmesan
• salt, to taste
• random source of capsaicin, to taste
• water

Proceed to the cooky part of the evening:

• Slice and cut all vegetables into sizes of your preference; personally, I like to stay on the chunky side, but do whatever you feel like.
• Pour the olive oil into the pot; optionally add oil from your sundried tomatoes and/or grilled peppers in case those came in oil.
• Put the pot onto high heat and toss the chopped vegetables in as soon as it starts heating up.
• Stir for maybe a minute, then add a bit of water.
• Toss in the noodles and add just enough water to cover everything.
• Now is a good time to add salt and capsaicin, to taste.
• Cook everything down on medium to high heat while stirring and scraping the bottom of the pot so nothing burns. You want to get as much water out of the mix as possible.
• Towards the end, maybe a minute before the noodles are al dente, wash the basil leaves and rip them into small pieces.
• Turn off the heat, add all basil and cheese, stir a few times, and serve.

If you don't have any of those ingredients on hand and/or want to add something else: Just do so. This is not an exact science and it will taste wonderful any way you make it.

Originally published on politi.kov I have been asked by a bunch of friends from outside of Brazil for my opinion regarding the recent elections we had in Brazil, and it is a bit complicated to explain it without some background, so I decided to write this piece providing a bit of history so that people can understand my opinion. The elections this year were a rematch of our traditional polarization between the workers party (PT) and the social democracy party (PSDB), which has been going on since 1994. PT and PSDB used to be allies. In the 80s, when the dictatorship dropped the law that forbade more than 2 parties, the opposition party, MDB, began breaking up in several smaller ones. PSDB was founded by politicians and intelectuals who were inspired by Europe s social democracy and political systems. Parliamentarism, for instance, is one of the historical causes of the party. The workers party had a more grassroots origin, with union leaders, marxist intelectuals and marxist-inspired catholic priests being the main founders. They drew their inspiration from the USSR and Cuba, and were very close to social movements. Some people have celebrated the reelection of Dilma Roussef as a victory of the left against the right. In my opinion that view is wrong for several reasons. First, because I disagree that PSDB and A cio Neves in particular are right-wing, both in terms of economics and social/moral issues. Second, because I believe Dilma s first government has taken a quite severe turn to the right in several topics that matter a lot to me. Since comparisons with PSDB s government during the 90s has been one of the main strategies of the campaign this year, I ll argue why I think it was actually a pretty good government with a lot of left in it. Unlike what happens in most other places, Brazil does not really have an actual right-wing party, economics-wise. Although we might see the birth of a couple in the near future, no current party is really against public health, education and social security being provided by the state as rights, or wants to decrease state size and lower taxes significantly. It should come as no surprise that even though it has undergone a lot of liberal reforms over the last 20 years, Brazil is still a very closed country, with very high import tariffs and a huge presence of the state in the economy. There is a certain consensus about all of that, with disagreements being essentially on implementation details, not goals. On the other hand, and contrary to popular belief, when it comes to social and moral issues we are a very conservative people. Ironically, the two parties which have been in power over the last 20 years are quite progressive, being historically proponents of diversity, minorities rights, reproductive rights. They have had to compromise on those causes to become viable alternatives, given the conservative nature of the majority of the voters. Despite their different origins and beliefs, both parties share socialist inclinations and were allies from the onset. That changed in 1992, when president Collor, who had been elected on a runoff against Lula (who PSDB supported), was impeached by Congress for corruption. With no formal political support and a chaotic situation in his hands, Itamar Franco, the vice president, called for a national union government to go through the last two years of his term. PSDB answered the call, but the workers party decided against being part of the government. Fernando Henrique Cardoso, a sociologist who was one of the leaders of PSDB was chosen to lead the Foreign Relations Ministry, but a few months later got nominated to the Economy. At the time, Brazil lived under hyperinflation of close to 1000% a year, and several stabilization plans had been attempted. Economy Ministers did not last very much in office at the time. FHC gathered a team of economists and sponsored their stabilization plan, which turned out to be highly successful: the Plano Real ( Real Plan ). In addition to introducing a new currency, something that was becoming pretty common to Brazilians by then, it also attacked the structural causes of inflation. Lula was counting on the failure of the Plano Real when he ran against FHC in 1994, but the plan succeeded, giving FHC two terms as president. During those two terms, FHC introduced several institutional changes that made Brazil a saner country. In addition to the hyperinflation, Brazil had lived a debt crises for decades and was still in default. FHC s team renegotiated the debts, reopened lines of credit, but most importantly, introduced reforms that made the Brazilian finances and financial system credible. The problem was not even that Brazil had a fiscal d ficit, it just did not have any control whatsoever of money supply and budget. Banks, regardless of whether they were private or public, had very little regulation and took advantage of the hyperinflation to hide monstrous holes in their balances. When inflation was gone and regulation became more strict, those became apparent, and it was pretty clear that the system would collapse if nothing was done. Some people like to say that FHC was a president who ruled for the rich and didn t care about the poor. I think the way the potential collapse of the banking system was handled is a great counter-example of that. The government passed laws that made the owners of the banks responsible for the financial problems, regardless of whether caused by mismanagement or fraud. If a bank went under, the central bank intervened and added enough money to protect the deposits, but that money was a loan that had to be repaid by the owners of the bank, and the owners properties were added as collateral to the loan. As a brazilian journalist once said, the people did not risk losing their deposits, the bankers did risk losing the banks, though. Today, we have a separate fund, filled with money from the banks, that does what the central bank did back then when required. Compare that to countries where the banking system was saved with tax payer money and executives kept getting huge bonuses regardless, while owners kept their profits. It is hard to find an initiative that is more focused on the public interest against the interest of the rich people who caused the problem. This legislation, called PROER, is still in place today, and it came along with solid regulation of the banking system. It should come as no surprise that Brazil went through the financial crisis of 2008 with not a single hiccup of the banking system and no fear of bank runs. Despite having been against PROER back in the day, Lula celebrated its existence in 2008, when it was clear it was one of the reasons we would not suffer much. He even advertised it as something that should be adopted by the US and Europe. It is also pretty common to hear that under FHC social questions were not a priority. I believe it is pretty simple to see that that was not the case both by inspecting the growth of social spending and the improvement of social indicators for the period, such as UN s human development index. One area in which people are particularly critical of the FHC government is the investment on higher education, and they are actually quite right. Brazil has free Federal universities and those did not get a lot of priority in the 90s. However, I would argue that while it is a matter of priorities, it is not one of education versus something else, but rather of what to invest on inside education. The reality is basic education was the priority. When FHC came to power, Brazil had a significant number of children who were not going to school at all. The goal was to make access to schools universal for young children, and that goal was reached. Every child has been going to school since the early 2000s, and that is a significant achievement which reaches the poorest. While the federal universities are attended essentially by the Brazilian elite, given the difficulty of passing the exams and the relative lack of quality of free public schools compared to private ones, which is still a reality to this day, investment on getting children to even go to school for the early years has a significant impact on the lives of the poorest. It is important to remember that getting every child to go to school is also what gave birth to one of the most celebrated programs from the Lula era: Bolsa Fam lia ( Family Allowance ) is a direct money transfer to poor families, particularly those who have children and has been an important contribution to lowering inequality and getting people out of extreme poverty. To get the money, the families need to ensure their children are 1) attending school and 2) getting vaccinated. That program comes from the FHC government, in which it was created with the name Bolsa Escola ( School Allowance ), in its turn inspired by a program of the same name by governor Cristovam Buarque, from PT. What Lula did, and he deserves a lot of credit for this, was to merge a series of smaller programs with Bolsa Escola, and then expand the program to ensure it got to more and more people. Interestingly, during the announcement of the program he credited the idea of doing that to a state governor from PSDB. You can see why I think these two should be allies again. When faced with all these arguments, people will eventually say that FHC was bad because he privatized companies and used orthodox economic policies. Well, if that is what it takes, then we ll have to take Lula down with him, because his first term was essentially a continuation of FHC s second term: orthodox economic policies to keep inflation down, along with privatization of several state-owned companies and banks. But Lula, whom I voted for and whose government I believe was a good one, is not my subject: Dilma is. On Lula s second term, Dilma gained a lot of power when other major leaders of PT went down for corruption. She became second in command and started leading several programs. A big believer in developmentalism, she started pushing for a bigger role of the state in the coordination of the productive sector, with a clear focus on growing the industrial base. One of the initiatives she sponsored was a sizable increase on the number and size of subsidized loans given out by the national development bank (BNDES). Brazil started an unnofficial national champions program, where the government elected a few big companies to get a huge amount of subsidized credit. The goal was for these selected firms to get big enough to be competitive on the global market. The criteria for the choices is completely opaque, if it even exists, and includes handing out milions in subsidized credit for Eike Batista, who became Brazil s richest enterpreneur for a while, and lost pretty much everything when it became clear the oil would not be pumping out of his camps after all, sinking with them a huge amount of public funds invested by BNDES. The way this policy was enacted, it is unclear how much it really costs in terms of public funds: the Brazilian treasury emits debt to capitalize, lends that money to BNDES with higher than market interest, and BNDES then lends it out to the big companies with a lower than market interest rate. Although it is obviously unsustainable, the problem does not yet show in the balance because the grace period for BNDES debt with the treasury is 2040. The fact that this has a cost and, perhaps more importantly, a huge opportunity cost is not clear because it is not part of the government budget. Why are we putting money in this rather than quadrupling Bolsa Fam lia, which studies show generates 1,78 reais in GDP for every 1 real invested? Worse, why are we not even updating Bolsa Fam lia enough to cover inflation? When Dilma got elected in 2010, the first signs were pretty bad. She was already seen as someone who did not care much for the environment, and on her first month in power she made good on that promise by pushing to get the Belo Monte Dam building started as soon as possible regardless of conditionalities being satisfied. To this day there are several issues with how the building of the dam is going: the handling of the indigenous people and the small city nearby are lacking, conditionalities are not met. Beyond Belo Monte, indigenous leaders are being assassinated, deforestation in the Amazon forest has increased by 122% in 2014 alone. Dilma s answer to people who question her on these kinds of issues is essentially: would you rather not have electric power? Her populist authoritarian nature and obsession with industry are also pretty evident when it comes to her policies in the energy area as a whole. She showed up in national tv on the eve of our independence day celebration to announce a reduction in electric tariffs, mainly for industry, but also for homes. Nobody really knew how. The following week she sent a fast-track project to Congress to automatically renew concessions of power grid operators, requiring those who accepted it to lower tariffs, instead of doing an auction, which was already necessary anyway because the concessions were up on 2015. There was no discussion with stakeholders, there was just a populist announcement and a great deal of rhethoric to paint anyone who opposed as being against the people. And now, everything went into the crapper because that represented a breach of contract that required indemnification, and we had a pretty bad drought that made power more expensive given the need to turn on the thermal generators. Combining the costs of the thermal generation, indemnity, and financial fallout that the grid operators suffered, we are already at 105 billion reais and counting, nobody knows how high the cost will reach. Any reduction in tariffs has long been invalidated. And the fact that industry has lowered production significantly ends up being good news, we would probably be under rationing already if that was not the case. You would expect someone who fought a dictatorship to be pretty good in terms of human and civil rights. What we see in reality is a lack of respect for those things. During the world cup, Dilma has put the army on the streets and has supported arbitrary behaviour from state polices throughout the country. They jailed a bunch of demonstrators preemptively. No shit. The would be demonstrators were kept in jail throghout the tournament under false accusations. Dilma s Minister of Justice said several times that the case against them was solid and that the arrests were legal, but it turned out the case simply did not exist. Just this week we had a number of executions orchestrated by policemen in the state of Par and there is zero reaction from the federal government. In the oil industry, Dilma has enacted a policy of subsidizing gas prices by using a fixed price that used to be lower than the international prices (it is no longer the case with the fall in international prices). That would not be a problem if Brazil was selfsufficient in oild and gas, which we are not: we had to import a significant amount of both. The implicit subsidy cost Petrobr s a huge amount of cash the more gas it sold, the bigger the losses. This lead not only to decreasing the company s market value (it is a state-controlled, but open company), but to reducing its capacity of investment as well. That is more problematic than it sounds because, with our current concession model, every single oil camp needs to have Petrobr s as a member of the consortium. Limiting the company s investment capacity limits the rate at which our pre-salt oil camps can be explored and thus the speed at which we can become selfsufficient. Chicken and egg anyone? To make things worse, Dilma has made policies that lowered taxes on car production, used to foster economic activity during the crisis in 2008-2010, essentially permanent. This lead to a significant increase in traffic and polution on Brazilian cities, while at the same time increasing the pressure on Petrobr s, which had to import more and more gas. Meanwhile, Brazilian cities suffer from a severe lack of mobility infrastructure. A recent study has shown that Brazil has spend almost twice as much subsidized money on pro-car policies than on pro-mass transit projects. Talk about good usage of public funds. One of the only remaining good news the government was still able to mention was the constant reduction in extreme poverty. Dilma was actually ellected promising to erradicate extreme poverty and changed the government s slogan to A rich country is a country with no poverty (Pa s rico pa s sem pobreza). Well, it turns out all of these policies caused inequality and extreme poverty both to stop falling as of 2013. And given the policies were actually deepened in 2014, I believe it is very likely we ll see an increase in both when we get the data for 2014, next year. Other than that, her policies ended up being a complete failure. Despite giving tax benefits to several sectors, investment has fallen, growth has fallen and inflation is quite high at 6,6% for the last 12 months. In terms of minorities, her government has been a severe set back, with the government going back on educational material against homophoby saying it would not do advertisement of sexual choice , and going back on a decree that allowed the public health system to perform abortions on the cases allowed by the law (essentially if the woman has been raped). Looking at Dilma s policies, I really can t see that much of the left, honestly. So why, you might ask, has this victory been deemed a victory of the left over the right? My explanation is the aura the workers party still manages to keep over itself. There s a notion that whatever PT does, it will still be more to the left than PSDB, which I think is just crazy. There is also a fair amount of idealizing Dilma just because she is Lula s proteg . People will forgive anything, provided it is the workers party doing it. Thankfully, the number of people aligned on the left that supported the candidate from PSDB this election tells me this is changing quite rapidly. Hopefully that leads to PT having to reinvent itself, and get in touch with the left again.

There s a lot of discussion / moaning /arguing at this time, so I thought I d post something about how LAVA got into Debian Jessie, the work involved and the lessons I ve learnt. Hopefully, it will help someone avoid the disappointment of having their package missing the migration into a future stable release. This was going to be a talk at the Minidebconf-uk in Cambridge but I decided to put this out as a permanent blog entry in the hope that it will be a useful reference for the future, not just Jessie. Context LAVA relies on a number of dependencies which were at the time all this started NEW to Debian as well as many others already in Debian. I d been running LAVA using packages on my own system for a few months before the packages were ready for use on the main servers (I never actually installed LAVA using the old virtualenv method on my own systems, except in a VM). I did do quite a lot of this on my own but I also had a team supporting the effort and valuing the benefits of moving to a packaged system. At the time, LAVA was based on Ubuntu (12.04 LTS Precise Pangolin) and a new Ubuntu LTS was close (Trusty Tahr 14.04) but I started work on this in 2013. By the time my packages were ready for general usage, it was winter 2013 and much too close to get anything into Ubuntu in time for Trusty. So I started a local repo using space provided by Linaro. At the same time, I started uploading the dependencies to Debian. json-schema-validator, django-testscenarios and others arrived in April and May 2014. (Trusty was released in April). LAVA arrived in NEW in May, being accepted into unstable at the end of June. LAVA arrived in testing for the first time in July 2014. Upstream development continued apace and a regular monthly upload, with some hotfixes in between, continued until close to the freeze. At this point, note that although upstream is a medium sized team, the Debian packaging also has a team but all the uploads were made by me. I planned ahead. I knew that I would be going to Macau for Linaro Connect in February a critical stage in the finalisation of the packages and the migration of existing instances from the old methods. I knew that I would be on vacation from August through to the end of September 2014 including at least two weeks with absolutely no connectivity of any kind. Right at this time, Django1.7 arrived in experimental with the intent to go into unstable and hence into Jessie. This was a headache for me, I initially sought to delay the migration until after Jessie. However, we discussed it upstream, allocated time within the busy schedule and also sought help from within Debian with the RFH tag. Rapha l Hertzog contributed patches for django1.7 support and we worked on those patches upstream, once I was back from vacation. (The final week of my vacation was a work conference, so we had everyone together at one hacking table.) Still there was more to do, the django1.7 patches allowed the unit tests to complete but broke other parts of the lava-server package and needed subsequent tweaks and fixes. Even with all this, the auto-removal from testing for packages affected by RC bugs in their dependencies became very important to monitor (it still is). It would be useful if some packages had less complex dependency chains (I m looking at you, uwsgi) as the auto-removal also covers build-depends. This led to some more headaches with libmatheval. I m not good with functional programming languages, I did have some exposure to Scheme when working on Gnucash upstream but it wasn t pleasant. The thought of fixing a scheme problem in the test suite of libmatheval was daunting. Again though, asking for help, I found people in the upstream team who wanted to refresh their use of scheme and were able to help out. The fix migrated into testing in October. Just for added complications, lava-server gained a few RC bugs of it s own during that time too fixed upstream but awkward nonetheless. Achievement unlocked So that s how a complex package like lava-server gets into stable. With a lot of help. The main problem with top-level packages like this is the sheer weight of the dependency chain. Something seemingly unrelated (like libmatheval) can seriously derail the migrations. The package doesn t use the matheval support provided by uwsgi. The bug in matheval wasn t in the parts of matheval used by uwsgi. It wasn t in a language I am at all comfortable in fixing but it s my name on the changelog of the NMU. That happened because I asked for help. OK, when django1.7 was scheduled to arrive in Debian unstable and I knew that lava was not ready, I reacted out of fear and anxiety. However, I sought help, help was provided and that help was enough to get upstream to a point where the side-effects of the required changes could be fixed. Maintaining a top-level package in Debian is becoming more like maintaining a core package in Debian and that is a good thing. When your package has a lot of dependencies, those dependencies become part of the maintenance workload of your package. It doesn t matter if those are install time dependencies, build dependencies or reverse dependencies. It doesn t actually matter if the issues in those packages are in languages you would personally wish to be expunged from the archive. It becomes your problem but not yours alone. Debian has a lot of flames right now and Enrico encouraged us to look at what else is actually happening in Debian besides those arguments. Well, on top of all this with lava, I also did what I could to help the arm64 port along and I m very happy that this has been accepted into Jessie as an official release architecture. That s a much bigger story than LAVA yet LAVA was and remains instrumental in how arm64 gained the support in the kernel and various upstreams which allowed patches to be accepted and fixes to be incorporated into Debian packages. So a roll call of helpers who may otherwise not have been recognised via changelogs, in no particular order:

• Steve McIntyre (Debian & Linaro)
• Rapha l Hertzog (Debian)
• Dave Pigott (Linaro)
• R mi Duraffort (Linaro)
• Sjoerd Simons (Debian)
• Antonio Terceiro (Debian and formerly Linaro)
• Martin Pitt (Debian)
• Jordi Mallach (Debian)
• Hector Oron (Debian)
• Colin Watson (Debian)

Also general thanks to the Debian FTP and Release teams. Lessons learnt

1. Allow time! None of the deadlines or timings involved in this entire process were hidden or unexpected. NEW always takes a finite but fairly lengthy amount of time but that was the only timeframe with any amount of uncertainty. That is actually a benefit it reminds you that this entire process is going to take a significant amount of time and the only loser if you try to rush it is going to be you and your package. Plan for the time and be sceptical about how much time is actually required.
2. Ask for help! Everyone in Debian is a volunteer. Yes, the upstream for this project is a team of developers paid to work on this code (and largely only this code) but the upstream also has priorities, requirements, objectives and deadlines. It s no good expecting upstream to do everything. It s no good leaving upstream insufficient time to fit the required work into the existing upstream schedules. So ask for help within upstream and within Debian ask for help wherever you can. You don t know who may be able to help you until you ask. Be clear when asking for help how would someone test their proposed fix? Exactly what are you asking for help doing? (Hint: everything is not a good answer.)
3. Keep on top of announcements and changes. The release team in Debian have made the timetable strict and have published regular updates, guidelines and status notes. As maintainer, it is your responsibility to keep up with those changes and make others in the upstream team aware of the changes and the implications. Upstream will rely on you to provide accurate information about these requirements. This is almost more important than actually providing the uploads or fixes. Without keeping people informed, even asking for help can turn out to be counter-productive. Communicate within Debian too talk to the teams, send status updates to bugs (even if the status is tag 123456 + help).
4. Be realistic! Life happens around us, things change, personal timetables get torn up. Time for voluntary activity can appear and disappear (it tends to disappear far more often than extends, so take that into account too).
5. Do not expect others to do the work for you asking for help is one thing, leaving the work to others is quite another. No complaining to the release team that they are blocking your work and avoid pleading or arguing when a decision is made. The policies and procedures within Debian are generally clear and there are quite enough arguments without adding more. Read the policies, read the guidelines, watch how other packages and other maintainers are handled and avoid those mistakes. Make it easy for others to help deliver what you want.
6. Get to know your dependency chain follow the links on the packages.debian.org pages and get a handle on which packages are relevant to your package. Subscribe to the bug pages for some of the more high-risk packages. There are tools to help. rc-alert can help you spot problems with runtime dependencies (you do have your own package installed on a system running unstable if not, get that running NOW). Watching build-dependencies is more difficult, especially build-dependencies of a runtime dependency, so watch the RC bug lists for packages in your dependency chain.

Above all else, remember why you and upstream want the packages in Debian in the first place. Debian is a respected distribution and has an acknowledged reputation for stability and portability. The very qualities that you and your upstream desire from having your package in Debian have direct implications for the amount of work and the amount of time that will be required to get your packages into Debian and keep them there. Having your package in Debian will bring considerable benefits but you will be required to invest a considerable amount of time. It is this contribution which is valuable to Debian and it is this work which will deliver the benefits you seek. Being an expert in the one package is wildly inadequate. Debian is about the system, the whole distribution and sooner or later, you as the maintainer will be absolutely required to handle something which is so far out of your comfort zone it s untrue. The reality is that you are not expected to fix that problem you are expected to handle that problem and that includes seeking and acknowledging the help of others. The story isn t over until release day. Having your package in testing the day before the freeze is one step. It may be a large step, but it is only one. The status of that package still needs monitoring. That long dependency chain can still come back and bite. Don t wait for problems to surprise you. Finally One thing I do ask is that other upstream teams and maintainers think about the dependency chain they are creating. It may sound nice to have bindings for every interpreted language possible when releasing your compiled library but it does not help people using that library. Yes, it is more work releasing the bindings separately because a stable API is going to be needed to allow version 1.2.3 to work alongside 1.2.2 and 1.3.0 or the entire effort is pointless. Consider how your upstream package migrates. Consider how adding yet another build-dependency for an optional component makes things exponentially harder for those who need to rely on that upstream. If it is truly optional, release it separately and keep backwards compatibility on each side. It is more work but in reality, all that is happening is that the work is being transferred from the distribution (where it helps only that one distribution and causes duplication into other distributions) into the upstream (where it helps all distributions). Think carefully about what constitutes core functionality and release the rest separately. Combining bindings for php, ruby, python, java, lua and xslt into a single upstream release tarball is a complete nonsense. It simply means that the package gets blocked from new uploads by the constant churn of being involved in every transition that occurs in the distribution. There is a very real risk that the package will miss a stable release simply by having fingers in too many pies. That hurts not only this upstream but every upstream trying to use any part of your code. Every developer likes to think that people are using and benefiting from their effort. It s not nice to directly harm the interests of other developers trying to use your code. It is not enough for the binary packages to be discrete migrations happen by source package and the released tarball needs to not include the optional bindings. It must be this way because it is the source package which determines whether version 1.2.3 of plugin foo can work with version 1.2.0 of the library as well as with version 1.3.0. Maintainers regularly deal with these issues so talk to your upstream teams and explain why this is important to that particular team. Help other maintainers use your code and help make it easier to make a stable release of Debian. The quicker the freeze & release process becomes, the quicker new upstream versions can be uploaded and backported.

As some of you already know, since the larger restructuring in PackageKit for the 1.0 release, I am rethinking Listaller, the 3rd-party application installer for Linux systems, as well. During the past weeks, I was playing around with a lot of different ideas and code, to make installations of 3rd-party software easily possible on Linux, but also working together with the distribution package manager. I now have come up with an experimental project, which might achieve this. Motivation Many of you know Lennart s famous blogpost on how we put together Linux distributions. And he makes a lot of good and valid points there (in fact, I agree with his reasoning there). The proposed solution, however, is not something which I am very excited about, at least not for the use-case of installing a simple application[1]. Leaving things like the exclusive dependency on technology like Btrfs aside, the solution outlined by Lennart basically bypasses the distribution itself, instead of working together with it. This results in a duplication of installed libraries, making it harder to overview which versions of which software component are actually running on the system. There is also a risk for security holes due to libraries not being updated. The security issues are worked around by a superior sandbox, which still needs to be implemented (but will definitively come soon, maybe next year). I wanted to explore a different approach of managing 3rd-party applications on Linux systems, which allows sharing as much code as possible between applications. Limba Glick2 and Listaller concepts merged In order to allow easy creation of software packages, as well as the ability to share software between different 3rd-party applications, I took heavy inspiration from Alexander Larssons Glick2 project, combining it with ideas from the application-directory based Listaller. The result is Limba (named after Limba tree, not the voodoo spirit I needed some name starting with li to keep the prefix used in Listaller, and for a tool like this the name didn t really matter ). Limba uses OverlayFS to combine an application with its dependencies before running it, as well as mount namespaces and shared subtrees. Except for OverlayFS, which just landed in the kernel recently, all other kernel features needed by Limba are available for years now (and many distributions ship with OverlayFS on older kernels as well). How does it work? In order to to achieve separation of software, each software component is located in a separate container (= package). A software component can be an application, like Kate or GEdit, but also be a single shared library (openssl) or even a full runtime (KDE Frameworks 5 parts, GNOME 3). Each of these software components can be identified via AppStream metadata, which is just a few bits of XML. A Limba package can declare a dependency on any other software component. In case that software is available in the distribution s repositories, the version found there can be used. Otherwise, another Limba package providing the software is required. Limba packages can be provided from software repositories (e.g. provided by the distributor), or be nested in other packages. For example, imagine the software Kate requires a version of the Qt5 libraries, >= 5.2. The downloadable package for Kate can be bundled with that dependency, by including the Qt5 5.2 Limba package in the Kate package. In case another software is installed later, which also requires the same version of Qt, the already installed version will be used. Since the software components are located in separate directories under /opt/software, an application will not automatically find its dependencies, or be able to locate its own files. Therefore, each application has to be run by a special tool, which merges the directory trees of the main application and it s dependencies together using OverlayFS. This has the nice sideeffect that the main application could override files from its dependencies, if necessary. The tool also sets up a new mount namespace, so if the application is compiled with a certain prefix, it does not need to be relocatable to find its data files. At installation time, to achieve better system integration, certain files (like e.g. the .desktop file) are split out of the installed directory tree, so the newly installed application achieves almost full system integration. AQNAY* Can I use Limba now? Limba is an experiment. I like it very much, but it might happen that I find some issues with it and kill it off again. So, if you feel adventurous, you can compile the source code and use the example Foobar application to play around with Limba. Before it can be used in production (if at all), some more time is needed. I will publish documentation on how to test the project soon. Doesn t OverlayFS have a maximum stacking depth? Oh yes it has! The How does it work explanation doesn t tell the whole truth in that regard (mainly to keep the section small). In fact, Limba will generate a runtime for the newly installed software, which is a directory with links to the actual individual software components the runtime consists of. The runtime is identified by an UUID. This runtime is then mounted together with the respective applications using OverlayFS. This works pretty great, and also results in no dependency-resolution to be done immediately before an application is started. Than dependency stuff gives me a headache Admittedly, allowing dependencies adds a whole lot of complexity. Other approaches, like the one outlined by Lennart work around that (and there are good reasons for doing that as well). In my opinion, the dependency-sharing and de-duplication of software components, as well as the ability to use the components which are packaged by your Linux distribution is worth the extra effort. Can you give an overview of future plans for Limba? Sure, so here is the stuff which currently works:

• Creating simple packages
• Installing packages
• Very basic dependency resolution (no relations (like >, <, =) are respected yet)
• Running applications
• Initial bits of system integration (.desktop files are registered)

These features are planned for the new future:

• Support for removing software
• Automatic software updates of 3rd-party software
• Atomic updates
• Better system integration
• Integration with the new sandboxing features
• GPG signing of packages
• More documentation / bugfixes

Remember that Limba is an experiment, still XKCD 927 Technically, I am replacing one solution with another one here, so the situation does not change at all ;-). But indeed, some duplicate work is done due to more people working in this area now on similar questions. But I think this is a good thing, because the solutions worked on are fundamentally different approaches, and by exploring multiple ways of doing things, we will come up with something great in the end. (XKCD reference) Doesn t the use of OverlayFS have an impact on the performance of software running with Limba? I ran some synthetic benchmarks and didn t notice any problems even the startup speed of Limba applications is only a few milliseconds slower than the startup of the raw native application. However, I will still have to run further tests to give a definitive answer on this. How do you solve ABI compatibility issues? This approach requires software to keep their ABI stable. But since software can have strict dependencies on a specific version of a software (although I d discourage that), even people who are worried about this issue can be happy. We are getting much better at tracking unwanted ABI breaks, and larger projects offer stable API/ABI during a major release cycle. For smaller dependencies, there are, as explained above, stricter dependencies. In summary, I don t think ABI incompatibilities will be a problem with this approach at least not more than they have been in general. (The libuild facilities from Listaller to minimize dependencies will still be present im Limba, of course) You are wrong because of $X! Please leave a comment in this case! I d love to discuss new ideas and find the limits of the Limba concept that s why I am writing C code afterall, since what looks great on paper might not work in reality or have issues one hasn t thought about before. So any input is welcomed! Conclusion Last but not least I want to thank Alexander Larsson for writing Glick2, which Limba is heavily inspired from, and for his patient replies to my emails. If Limba turns out to be a good idea, you can expect a few more blog posts about it soon.

---

* Answered questions nobody asked yet [1]: Don t get me wrong, I would like to have these ideas implemented they offer great value. But I think for simple software deployment, the solution is an overkill.