Disclaimer: I m not used to writing personal stuff on Debian channels. However, there is nothing new here for those who know me from other public channels.


Yesterday, I received the weirdest email from well-known troll MikeeUSA. He thought I shared his views of a horrible world full of bloodthirsty feminists using systemd in their quest for domination over poor white male heterosexuals. The most nauseating paragraph was probably the one where he showed signs of the mentality of a pedocriminal.

At first, I shrugged it off and sent him an email explaining I didn t want anything with his stinky white male supremacist theories, assorted with a bit of taunting. But after discovering all that stuff was actually sent to public mailing lists, I took the time for a second look and started a bit of introspection.

MikeeUSA thought I was a white male supremacist because of the so-called SmellyWerewolf incident, 6 years ago.
Oh boy, people change in six years. Upon re-reading that, I had trouble admitting I was the one to write it. Memory is selective, and with time, you tend not to remember some gruesome details, especially the ones that conflict most with your moral values.

I can assure every reader that the only people I intended to mock then were those who mistook Debian mailing lists for advertising channels; but I understand now that my message must have caused pain to a lot more people than that. So, it may come late, but let me take this opportunity to offer my sincerest apologies to anyone I may have hurt at that time.


It may seem strange for someone with deeply-rooted values of equality to have written that. To have considered that it was okay to stereotype people. And I think I found this okay because to me, those people were given equal rights, and were therefore equal. But the fight for equality is not over when everyone is given the same rights. Not until they are given the same opportunities to exert those rights. Which does not happen when they live in a society that likes to fit them in little archetypal peg holes, never giving you the chance to question where those stereotypes come from.

For me, that chance came from an unusual direction: the fight against prostitution. This goes way back for me. Since when I was a teenager, I have always been ticked off at the idea of nonconsensual sex that somehow evades criminal responsibility because of money compensation. I never understood why it wasn t considered as rape. Yet it sounded weird that a male heterosexual would hold such opinions; after all, male heterosexuals should go to prostitutes as a kind of social ritual, right?

It was only three years ago that an organization of men against prostitution was founded in France. Not only did I find out that I was not alone with my progressive ideas, I was given the opportunity to exchange with many men and women who had studied prostitution: its effects on victims, its relationship to rape culture and more generally to the place men and women hold in society. Because eventually, it all boils down to little peg holes in which we expect people to fit: the virile man or the faggot, the whore or the mother. For me, it was liberating. I could finally get rid of the discomfort of being a white male heterosexual that didn t enter the little peg holes that were made for me.

And now, after Sweden 15 years ago, a new group of countries are finally adopting laws to criminalize the act of paying for sex. Including France. That s too bad for MikeeUSA, but this country is no longer the eldorado for white male supremacists. And I m proud that our lobbying made a contribution, however small, to that change.

after see attic introduced in a discussion about bup, i figured out i could give it a try. it was answering two of my biggest concerns with bup:

• backup removal
• encryption

and seemed to magically out of nowhere and basically do everything i need, with an inline manual on top of it.

disclaimer Note: this is not a real benchmark! i would probably need to port bup and attic to liw's seivot software to report on this properly (and that would amazing and really interesting, but it's late now). even worse, this was done on a production server with other stuff going on so take results with a grain of salt.

procedure and results Here's what I did. I setup backups of my ridiculously huge ~/src directory on the external hard drive where I usually make my backups. I ran a clean backup with attic, than redid it, then I ran a similar backup with bup, then redid it. Here are the results:

anarcat@marcos:~$ sudo apt-get install attic # this installed 0.13 on debian jessie amd64
[...]
anarcat@marcos:~$ attic init /mnt/attic-test:
Initializing repository at "/media/anarcat/calyx/attic-test"
Encryption NOT enabled.
Use the "--encryption=passphrase keyfile" to enable encryption.
anarcat@marcos:~$ time attic create --stats /mnt/attic-test::src ~/src/
Initializing cache...
------------------------------------------------------------------------------
Archive name: src
Archive fingerprint: 7bdcea8a101dc233d7c122e3f69e67e5b03dbb62596d0b70f5b0759d446d9ed0
Start time: Tue Nov 18 00:42:52 2014
End time: Tue Nov 18 00:54:00 2014
Duration: 11 minutes 8.26 seconds
Number of files: 283910
                       Original size      Compressed size    Deduplicated size
This archive:                6.74 GB              4.27 GB              2.99 GB
All archives:                6.74 GB              4.27 GB              2.99 GB
------------------------------------------------------------------------------
311.60user 68.28system 11:08.49elapsed 56%CPU (0avgtext+0avgdata 122824maxresident)k
15279400inputs+6788816outputs (0major+3258848minor)pagefaults 0swaps
anarcat@marcos:~$ time attic create --stats /mnt/attic-test::src-2014-11-18 ~/src/
------------------------------------------------------------------------------
Archive name: src-2014-11-18
Archive fingerprint: be840f1a49b1deb76aea1cb667d812511943cfb7fee67f0dddc57368bd61c4bf
Start time: Tue Nov 18 00:05:57 2014
End time: Tue Nov 18 00:06:35 2014
Duration: 38.15 seconds
Number of files: 283910
                       Original size      Compressed size    Deduplicated size
This archive:                6.74 GB              4.27 GB            116.63 kB
All archives:               13.47 GB              8.54 GB              3.00 GB
------------------------------------------------------------------------------
30.60user 4.66system 0:38.38elapsed 91%CPU (0avgtext+0avgdata 104688maxresident)k
18264inputs+258696outputs (0major+36892minor)pagefaults 0swaps
anarcat@marcos:~$ sudo apt-get install bup # this installed bup 0.25
anarcat@marcos:~$ free && sync && echo 3   sudo tee /proc/sys/vm/drop_caches && free # flush caches
anarcat@marcos:~$ export BUP_DIR=/mnt/bup-test
anarcat@marcos:~$ bup init
D p t Git vide initialis  dans /mnt/bup-test/
anarcat@marcos:~$ time bup index ~/src
Indexing: 345249, done.
56.57user 14.37system 1:45.29elapsed 67%CPU (0avgtext+0avgdata 85236maxresident)k
699920inputs+104624outputs (4major+25970minor)pagefaults 0swaps
anarcat@marcos:~$ time bup save -n src ~/src
Reading index: 345249, done.
bloom: creating from 1 file (200000 objects).
bloom: adding 1 file (200000 objects).
bloom: creating from 3 files (600000 objects).
Saving: 100.00% (6749592/6749592k, 345249/345249 files), done.
bloom: adding 1 file (126005 objects).
383.08user 61.37system 10:52.68elapsed 68%CPU (0avgtext+0avgdata 194256maxresident)k
14638104inputs+5944384outputs (50major+299868minor)pagefaults 0swaps
anarcat@marcos:attic$ time bup index ~/src
Indexing: 345249, done.
56.13user 13.08system 1:38.65elapsed 70%CPU (0avgtext+0avgdata 133848maxresident)k
806144inputs+104824outputs (137major+38463minor)pagefaults 0swaps
anarcat@marcos:attic$ time bup save -n src2 ~/src
Reading index: 1, done.
Saving: 100.00% (0/0k, 1/1 files), done.
bloom: adding 1 file (1 object).
0.22user 0.05system 0:00.66elapsed 42%CPU (0avgtext+0avgdata 17088maxresident)k
10088inputs+88outputs (39major+15194minor)pagefaults 0swaps

Disk usage is comparable:

anarcat@marcos:attic$ du -sc /mnt/*attic*
2943532K        /mnt/attic-test
2969544K        /mnt/bup-test

People are encouraged to try and reproduce those results, which should be fairly trivial.

Observations Here are interesting things I noted while working with both tools:

• attic is Python3: i could compile it, with dependencies, by doing apt-get build-dep attic and running setup.py - i could also install it with pip if i needed to (but i didn't)
• bup is Python 2, and has a scary makefile
• both have an init command that basically does almost nothing and takes little enough time that i'm ignoring it in the benchmarks
• attic backups are a single command, bup requires me to know that i first want to index and then save, which is a little confusing
• bup has nice progress information, especially during save (because when it loaded the index, it knew how much was remaining) - just because of that, bup "feels" faster
• bup, however, lets me know about its deep internals (like now i know it uses a bloom filter) which is probably barely understandable by most people
• on the contrary, attic gives me useful information about the size of my backups, including the size of the current increment
• it is not possible to get that information from bup, even after the fact - you need to du before and after the backup
• attic modifies the files access times when backing up, while bup is more careful (there's a pull request to fix this in attic, which is how i found out about this)
• both backup systems seem to produce roughly the same data size from the same input

Summary attic and bup are about equally fast. bup took 30 seconds less than attic to save the files, but that's not counting the 1m45s it took indexing them, so on the total run time, bup was actually slower. attic is also (almost) two times faster on the second run as well. but this could be within the margin of error of this very quick experiment, so my provisional verdict for now would be that they are about as fast. bup may be more robust (for example it doesn't modify the atimes), but this has not been extensively tested and is more based with my familiarity with the "conservatism" of the bup team rather than actual tests. considering all the features promised by attic, it makes for a really serious contender to the already amazing bup.

Next steps The properly do this, we would need to:

• include other software (thinking of Zbackup, Burp, ddar, obnam, rdiff-backup and duplicity)
• bench attic with the noatime patch
• bench dev attic vs dev bup
• bench data removal
• bench encryption
• test data recovery
• run multiple backup runs, on different datasets, on a cleaner environment
• ideally, extend seivot to do all of that

Note that the Burp author already did an impressive comparative benchmark of a bunch of those tools for the burp2 design paper, but it unfortunately doesn't include attic or clear ways to reproduce the results.

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.

Following mini-Debconf and submitting my key to keyring-maint, here's a copy of the note marking the transition. I do retain a copy of the old key: it has not been compromised or revoked (until I'm sure my new key reaches the Debian keyring) and my vote in the GR is validly signed with the old key.

Date: Wed, 12 Nov 2014 08:11:53 +0000
From: "Andrew M.A. Cater"
To: keyring@rt.debian.org
Subject: Debian RT - new key for amacater
User-Agent: Mutt/1.5.23 (2014-03-12)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pub 1024D/E93ADE7B 2001-07-04
Key fingerprint = F3FA 2752 1327 7904 846D C0DE 3233 C127 E93A DE7B
uid Andrew Cater (Andrew M.A. Cater)
sub 1024g/E8C8CC00 2001-07-04

pub 4096R/22EF1F0F 2014-08-29
Key fingerprint = 5596 5E39 93E0 6E2B 5BA5 CD84 4AA8 FC24 22EF 1F0F
uid Andrew M.A. Cater (Andy Cater)
uid Andrew M.A. Cater (non-Debian email)
sub 4096R/923AB77E 2014-08-29


This is intended to replace the old key by the new key as part of a key transition from old, insecure keys

All the best,

AndyC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlRipvgACgkQMjPBJ+k63nvaQACeM9OpQsFb2qzsmNRPH6fwLh5M
zhIAn19XSkKYF85Tj2kvuC5wl7PVSYPS

This because Google (and Planet Debian) are more reliable than my email inbox.

[Keys exchanged at the mini-Debconf have now been signed with the new 4096 bit key]

AndyC

For the second year running, we held our mini-debconf in Cambridge last weekend. Roughly 70 people turned up this year to the ARM offices in Cambridge over the 4 days. Alongside our originally planned general sprint work on Thursday and Friday, the Release Team had their own sprint to work through remaining post-freeze decisions about policies, architectures, naming etc. The rest of us worked through a range of topics all over Debian: installer, admin, ARM arch support etc. We even managed to fix Andy's laptop :-). Saturday and Sunday were two days devoted to more traditional conference sessions. Our talks covered a wide range of topics: d-i progress and an update from the Release Team, backup software and an arm64 laptop project to name but a few. I was very happy that the Release Team announced Zurg"Stretch" and "Buster" as upcoming release names, and obviously it was lovely to have arm64 and ppc64el confirmed as release architectures for Jessie. It's a shame to see the kfreebsd ports dropped from the official Jessie list, but let's see if the porters can do an unofficial release anyway. I'll help if I can with things like CD builds... Several volunteers from the DebConf video team were on hand too, so our talks were recorded and are already online at http://meetings-archive.debian.net/pub/debian-meetings/2014/mini-debconf-cambridge/webm/. Yay! Again, the mini-conf went well and feedback from attendees was universally positive. We may run again next year. More importantly, I can confirm that we're definitely planning on bidding to host a full DebConf in Cambridge in the summer of 2017. Thanks to all our helpers, and of course to our sponsors: ARM for providing the venue and infrastructure for the event, and Codethink for helping with food costs.

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.

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.

The right to communicate with your friends and family in private, without anyone snooping, is a right every citicen have in a liberal democracy. But this right is under serious attack these days. A while back it occurred to me that one way to make the dragnet surveillance conducted by NSA, GCHQ, FRA and others (and confirmed by the whisleblower Snowden) more expensive for Internet email, is to deliver all email using SMTP via Tor. Such SMTP option would be a nice addition to the FreedomBox project if we could send email between FreedomBox machines without leaking metadata about the emails to the people peeking on the wire. I proposed this on the FreedomBox project mailing list in October and got a lot of useful feedback and suggestions. It also became obvious to me that this was not a novel idea, as the same idea was tested and documented by Johannes Berg as early as 2006, and both the Mailpile and the Cables systems propose a similar method / protocol to pass emails between users. To implement such system one need to set up a Tor hidden service providing the SMTP protocol on port 25, and use email addresses looking like username@hidden-service-name.onion. With such addresses the connections to port 25 on hidden-service-name.onion using Tor will go to the correct SMTP server. To do this, one need to configure the Tor daemon to provide the hidden service and the mail server to accept emails for this .onion domain. To learn more about Exim configuration in Debian and test the design provided by Johannes Berg in his FAQ, I set out yesterday to create a Debian package for making it trivial to set up such SMTP over Tor service based on Debian. Getting it to work were fairly easy, and the source code for the Debian package is available from github. I plan to move it into Debian if further testing prove this to be a useful approach. If you want to test this, set up a blank Debian machine without any mail system installed (or run apt-get purge exim4-config to get rid of exim4). Install tor, clone the git repository mentioned above, build the deb and install it on the machine. Next, run /usr/lib/exim4-smtorp/setup-exim-hidden-service and follow the instructions to get the service up and running. Restart tor and exim when it is done, and test mail delivery using swaks like this:

torsocks swaks --server dutlqrrmjhtfa3vp.onion \
  --to fbx@dutlqrrmjhtfa3vp.onion

This will test the SMTP delivery using tor. Replace the email address with your own address to test your server. :) The setup procedure is still to complex, and I hope it can be made easier and more automatic. Especially the tor setup need more work. Also, the package include a tor-smtp tool written in C, but its task should probably be rewritten in some script language to make the deb architecture independent. It would probably also make the code easier to review. The tor-smtp tool currently need to listen on a socket for exim to talk to it and is started using xinetd. It would be better if no daemon and no socket is needed. I suspect it is possible to get exim to run a command line tool for delivery instead of talking to a socket, and hope to figure out how in a future version of this system. Until I wipe my test machine, I can be reached using the fbx@dutlqrrmjhtfa3vp.onion mail address, deliverable over SMTorP. :)

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.

I posted this on debian-devel today. I am also posting it here, because I believe it is important to more than just Debian developers. Good afternoon, This message comes on the heels of Sam Hartman s wonderful plea for compassion [1] and the sad news of Joey Hess s resignation from Debian [2]. I no longer frequently post to this list, but when you ve been a Debian developer for 18 years, and still care deeply about the community and the project, perhaps you have a bit of perspective to share. Let me start with this: Debian is not a Free Software project. Debian is a making-the-world-better project, a caring for people project, a freedom-spreading project. Free Software is our tool. As many of you, hopefully all of you, I joined Debian because I enjoyed working on this project. We all did, didn t we? We joined Debian because it was fun, because we were passionate about it, because we wanted to make the world a better place and have fun doing it. In short, Debian is life-giving, both to its developers and its users. As volunteers, it is healthy to step back every so often, and ask ourselves two questions: 1) Is this activity still life-giving for me? 2) Is it life-giving for others? I have my opinions about init. Strong ones, in fact. [3] They re not terribly relevant to this post. Because I can see that they are not really all that relevant. 14 years ago, I proposed what was, until now anyhow, one of the most controversial GRs in Debian history. It didn t go the way I hoped. I cared about it deeply then, and still care about the principles. I had two choices: I could be angry and let that process ruin my enjoyment of Debian. Or I could let it pass, and continue to have fun working on a project that I love. I am glad I chose the latter. Remember, for today, one way or another, jessie will still boot. 18 years ago when I joined Debian, our major concerns were helping newbies figure out how to compile their kernels, finding manuals for monitors so we could set the X modelines properly, finding some sort of Free web browser, finding some acceptable Office-type software. Wow. We WON, didn t we? Not just Debian, but everyone. Freedom won. I promise you 18 years from now, it will not matter what init Debian chose in 2014. It will probably barely matter in 3 years. This is not key to our goals of making the world a better place. Jessie will still boot. I say that even though my system runs out of memory every few days because systemd-logind has a mysterious bug [4]. It will be fixed. I say that even though I don t know what init system it will use, or how much choice there will be. I say that because it is simply true. We are Debian. We will make it work, one way or another. I don t post much on this list anymore because my personal passion isn t with posting on this list anymore. I make liberal use of my Delete Thread keybinding on -vote these days, because although I care about the GR, I don t care about it enough to read all the messages about it. I have not yet decided if I will spend the time researching it in order to vote. Instead of debating the init GR, sometimes I sit on the sofa with my wife. Sometimes I go out and fly the remote-control airplane I m learning to fly. Sometimes I repair my plane after a flight that was shorter than planned. Sometimes I play games with my boys, or help them with homework, or share my 8-year-old s delight as a text file full of facts about the Titanic that he wrote in Emacs comes spitting out of the printer. Sometimes I write code or play with the latest Linux filesystems or build a new server for my basement. All these things matter more to me than init. I have been using Debian at home for almost 20 years, at various workplaces for almost that long, and it is not going to stop being a part of my life any time soon. Perhaps I will have to learn how to administer a new init system. Well, so be it; I enjoy learning new things. Or perhaps I will have to learn to live with some desktop limitations with an old init system. Well, so be it; it won t bother me much anyhow. Either way, I m still going to be using what is, to me, the best operating system in the world, made by one of the world s foremost Freedom projects. My hope is that all of you may also have the sense of peace I do, that you may have your strong convictions, but may put them all in perspective. That we as a project realize that the enemy isn t the lovers of the other init, but the people that would use law and technology to repress people all over the world. We are but one shining beacon on a hill, but the world will be worse off if our beacon winked out. My plea is that we each may get angry at what matters, and let go of the smaller frustrations in life; that we may each find something more important than init/systemd to derive enjoyment and meaning from. [5] May you each find that airplane to soar freely in the skies, to lift your soul so that the joy of using Free Software to make the world a better place may still be here, regardless of what /sbin/init is. [1] https://lists.debian.org/debian-project/2014/11/msg00002.html [2] https://lists.debian.org/debian-devel/2014/11/msg00174.html [3] A hint might be that in my more grumpy moments, I realize I haven t ever quite figured out why the heck this dbus thing is on so many of my systems, or why I have to edit XML to configure it ;-) [4] #765870 [5] No disrespect meant to the init/systemd maintainers. Keep enjoying what you do, too!

I ve been working on a significant rearchitecture of Debian Code Search during the last few months (off and on, as time permits). This will enable us to provide a couple of features that have been often requested but were not possible with the old architecture, such as grouping search results by Debian source package (#1 feature request) and performing queries that take a longer time than the default execution limit of a minute (#2 feature request). Oh, and it also will be a lot faster :-). All of this (unfortunately?) also requires a redesign of the user interface as the old way of displaying results is just fundamentally incompatible with the new architecture. This is why it s taking longer than I d like (never redesign both backend and frontend at the same time), but I m implementing various nice improvements along the way and I think the result will be worth the wait. Lea has helped me a lot re-designing the visual appearence of the search results page, and the new look (of the upcoming group by package feature!) is what I want to share in this blog post. If you have any comments, please let me know (via email to my debian address, stapelberg@). Enjoy:

Fun and Sanity in Debian A friend of mine recently asked: "is there anything happening in Debian besides systemd?" Of course there is. He asked it 2 days after the freeze, which happened in time, and with an amazingly low RC bug count. The most visible thing right now seems to be this endless init system argument, but there are fun and sane things in Debian. Many of them. I think someone should put the spotlight on them, and here's my attempt. Yesterday I set up a gobby document asking "What is now happening in Debian that is exciting, fun and sane?", and passed the link around the Cambridge Miniconf and some IRC channels. Here are a few quotations that I collected:

The armhf and arm64 ports have for me been wonderful and exciting, and were a great time for me to start getting involved. (Jon "Aardvark" Ward) We have a way of tracking random contributors, and as far as I know no other project has anything like it. (Enrico Zini) codesearch.debian.net is an incredibly important resource, not just for us but for the free software community at large. (Ben Hutchings) sources.debian.net is a very useful resource with lots of interested contributors, it received 10 OPW applicants (Stefano Zacchiroli) It has never been easier to work on new infrastructure project thanks to the awesome work of the DSA team. We have dozens of contribution opportunities outside of just plain packaging. (Rapha l Hertzog) The work on reproducible builds has achieved excellent results with 61.3% of packages being reproducible. (Paul Wise) Porting arm64 has been (peversely) great fun. It's remarkably morish and I like nothing more than a tedious argument with autoconf macros. Working with lots of enthusiastic people from other teams, helping getting the port set up and build has been great - thank you everybody. (Wookey)

And here are random exciting things that were listed:

• build-profile support (for bootstrapping) is all in jessie (dpkg, apt, sbuild, python-apt, debhelper, libconfig-model-dpkg-perl, lintian).
• PointCloudLibrary (PCL) got migrated from Ubuntu to Debian
• Long Term Support has arrived!
• http://ci.debian.net
• Debian is participating for the second time in OPW as mentor orga
• ftp-master is getting an API
• cross-toolchains for jessie are available
• arm64/ppc64el ready to go into jessie
• wheezy-backports is more useful and used than ever
• we froze, in time, with a remarkably low RC bug count, and we have a concrete plan for getting from that to a release

Jessie was frozen on November 5th, as planned. At the time of the freeze, 310 RC bugs remained to be fixed. This is quite an achievement from the project as a whole, and the Release Team specifically. First, we froze on the date announced more than a year ago, and the freeze seems to have been well respected by all maintainers. Second, with 310 RC bugs at the time of the freeze, we are probably breaking a record for all recent Debian releases (though I don t have hard numbers for that). It seems that auto-removals of RC-buggy non-key packages helped a lot to keep the bug number under control. Assuming that all RC-buggy non-key packages were removed (which would be quite sad of course), we would even be down to about 150 RC bugs! Could we have the shorter Debian freeze ever? (wheezy: 44 weeks; squeeze: 26 weeks; lenny: 28 weeks; etch: 17 weeks). Given that FOSDEM is 12 weeks away, could we even release before FOSDEM, and have a big party there to celebrate? That s not impossible, but we need everybody s help. Random tip and tricks:

• Richard Hartmann s weekly stats are actually generated from this web page, that provides a good live breakdown of RC bugs per category. Some RC bugs are hard, but some just deserve more attention. Some ideas of rather easy tasks:
  • In the RC bugs list, sort bugs by last modification, take a bug that wasn t worked on recently, and try to provide a summary of the situation and of possible actions.
  • In the RC bugs list, sort bugs by bug number, and look at recent bugs: you might be among the first ones to look at them, so there might still be easy ways to make progress.
  • Review and analyze proposed solutions in the lists of bugs with patches, or which have been fixed in unstable but not unblocked yet.
  • And of course, try to attack the bulk of bugs without known fixes, and advance towards such a fix!
• If you are not so good at fixing bugs, do like me, and become good at opening new (real) bugs: the sooner they will be found, the sooner they can be fixed! I just opened ~100 RC bugs this morning, caused by packages failing to build from source in jessie.

Last friday saw a somewhat distressing email to the debian-devel mailinglist, wherein Joey Hess, one of Debian's most valuable contributors, announced his decision to quit the project. For all of Joey's contributions over the years, this is an unwelcome message; I'd much rather have seen him remain active in Debian, both on a personal and a technical level. As it is, I have a feeling of not just losing a colleague in Debian, but also a friend. For people not active in Debian, it's easy to miss Joey's contributions to the project, but let me tell you that without Joey Hess, Debian simply would not be where it is today. We would not have the debian-installer and we would not have debhelper (so we would have massively complicated debian/rules files). More than that, though, Joey has been one of those people who, on a technical level, seemed to instinctively sense the right thing to do; as in, whenever Joey Hess disagrees with you on a technical matter, you know you must be doing something wrong. As sudden and as unwelcome as last friday's announcement was, however, I can't say that it was totally unexpected. I've noticed Joey reducing his efforts in core areas of the project over the past few years, where on the one hand he has been mostly withdrawing from debian-installer development, and on the other hand his two most recent 'large' projects (ikiwiki and git-annex) haven't really been about Debian. Still, it's a painful loss; and while Debian has lost other high-profile contributors in the past over divisive issues, and recovered, that doesn't make it any less fun. Here's to you, Joey. May you find joy in whatever you decide to do next. May you not disappear from our collective radars. May we meet again, at some conference in the future, so I can buy you a beer. (hint: FOSDEM )

This evening, after the boys were in bed, Laura and I sat down to an episode of MASH (a TV series from the 70s) and leftover homemade pumpkin bars. She commented, Sometimes I wonder what generation we re in. This doesn t seem to be something people our age are usually doing. Probably true. I suppose people my age aren t usually learning to play the penny whistle or put up antennas in trees either. We ve had a fun day today a different sort of day in a lot of ways. We took the boys for their first Wichita Symphony Orchestra experience they were doing their first-ever family concert (Beethoven Lived Upstairs, which combined Beethoven s music with a two-person play aimed at kids). And they had an instrument petting zoo beforehand. Both boys loved it.

From November 8, 2014

After that, we took them to a sushi place for the first time. We ordered different types of rolls for our table, encouraging them to start with the California roll. They loved it (though Oliver did complain it was a bit hard to eat). Jacob happily devoured everything he could that wasn t spicy. He would have probably devoured the plate of California roll slices by himself if I hadn t stopped him and encouraged him to slow down and try some other things too. It doesn t seem very common around here to take 5-year-olds to a sushi place and plan on them eating the same sort of food that the adults around them are. It is a lot of fun to be different. Jacob and Oliver both have their unique personalities and interests, and I hope that they continue to find strength and joy in all the ways they are unique.

Here at the Debian mini-conf in Cambridge at ARM.

16 developers sat in near-total silence, the only noise keyboards and a server sitting next to me.

Some of them I've seen only on video presentations: one I first knew 20 years ago, one wrote all the HOWTO's I knew a couple of years before that - and was the second Linux user ever.

The release team is in another room behind me: Jessie froze the night before last - whatever else will be said/done, we're on the path to release.

It feels very strange and comforting to see Debian in the round: to be able to talk to someone you might argue with in email and see a real person.

And HUGE thanks to all at ARM for time, effort, chasing around and to Sledge and Jo Jo most of all for being stuck on a front desk waiting for people :)

Linaro uses LAVA as a tool to test variety of devices. So far I had not installed it myself, mostly due to assuming it to be enermously complex to set up. But thanks to Neil Williams work on packaging, installation has got a lot easier. Follow the Official Install Doc and Official install to debian Doc, roughly looking like: 1. Install Jessie into kvm

kvm -m 2048 -drive file=lava2.img,if=virtio -cdrom debian-testing-amd64-netinst.iso

2. Install lava-server

apt-get update; apt-get install -y postgresql nfs-kernel-server apache2
apt-get install lava-server
# answer debconf questions
a2dissite 000-default && a2ensite lava-server.conf 
service apache2 reload
lava-server manage createsuperuser --username default --email=foo.bar@example.com
$EDITOR /etc/lava-dispatcher/lava-dispatcher.conf # make sure LAVA_SERVER_IP is right

That's the generic setup. Now you can point your browser to the IP address of the kvm machine, and log in with the default user and the password you made. 3 ... 1000 Each LAVA instance is site customized for the boards, network, serial ports, etc. In this example, I now add a single arndale board.

cp /usr/lib/python2.7/dist-packages/lava_dispatcher/default-config/lava-dispatcher/device-types/arndale.conf /etc/lava-dispatcher/device-types/
sudo /usr/share/lava-server/add_device.py -s arndale arndale-01 -t 7001

This generates us a almost usable config for the arndale. For site specifics I have usb-to-serial. Outside kvm, I provide access to serial ports using the following ser2net config:

7001:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT
7002:telnet:0:/dev/ttyUSB1:115200 8DATABITS NONE 1STOPBIT

TODO: make ser2net not run as root and ensure usb2serial devices always get same name.. For automatic power reset, I wanted something cheap, yet something that wouldn't require much soldering (I'm not a real embedded engineer.. I prefer software side ;) . Discussed with Hector, who hinted about prebuilt relay boxes. Chose one from Ebay, a kmtronic 8-port USB Relay. So now I have this cute boxed nonsense hack. The USB relay is driven with a short script, hard-reset-1

stty -F /dev/ttyACM0 9600
echo -e '\xFF\x01\x00' > /dev/ttyACM0
sleep 1
echo -e '\xFF\x01\x01' > /dev/ttyACM0

Sidenote: If you don't have or want automated power relay for lava, you can always replace this this script with something along "mpg123 puny_human_press_the_power_button_now.mp3" Both the serial port and reset script are on server with dns name aimless. So we take the /etc/lava-dispatcher/devices/arndale-01.conf that add_device.py created and make it look like:

device_type = arndale
hostname = arndale-01
connection_command = telnet aimless 7001
hard_reset_command = slogin lava@aimless -i /etc/lava-dispatcher/id_rsa /home/lava/hard-reset-1

Since in my case I'm only going to test with tftp/nfs boot, the arndale board needs only to be setup to have a u-boot bootloader ready on power-on. Now everything is ready for a test job. I have a locally built kernel and device tree, and I export the directory using the httpd available by default in debian.. Python!

cd out/
python -m SimpleHTTPServer

Go to the lava web server, select api->tokens and create a new token. Next we add the token and use it to submit a job

$ sudo apt-get install lava-tool
$ lava-tool auth-add http://default@lava-server/RPC2/
$ lava-tool submit-job http://default@lava-server/RPC2/ lava_test.json
submitted as job id: 1
$

The first job should now be visible in the lava web frontend, in the scheduler -> jobs part. If everything goes fine, the relay will click in a moment and the job will finish in a few minutes.

While I don't consider myself part of the science fiction community directly (my con-going days are probably over), I do follow it across a wide variety of blogs. There are a lot of hard conversations and considerable soul-searching going on right now concerning an on-line commentator in that community who had been nasty and vicious to people, but originally for reasons that many people thought were good causes. (I had been one of those people. It's always very, very tempting to appreciate a good vitriolic rant from someone who shares your world view. And very easy to lose track of the people those rants are aimed at, or the excesses to which those rants go.) I'm not going to go into the details of the SF community issues here, since I have no context other than what I've read, and it's something to work out within that community. But I've been taking it as a useful reminder that abusive behavior is not acceptable, even if it comes from people who are arguably on your side. Anger is important. Anger is often how the world changes. But anger and abuse are not the same thing. I wrote something a little bit ago in a different context. Given that reminder, and given some of the arguments that are going on in the free software community as well, it seemed like a good idea to post a somewhat edited version of it in a more public place: None of us should be willing to continue to participate in a project in which we're expected to tolerate being abused and attacked, and all consequences of that abuse are our problem to deal with. It is simply not fun, and not motivating, and not interesting, and does not lead to us doing good work. I say this from lots of hard-won personal experience. I was deeply involved in Usenet governance for many years. I have made all the same arguments that I see today in favor of "blunt" speech, vitriol, and attacks. I have been a passionate advocate for the "free speech" approach. I have told other people to just filter and use killfiles. I have said that words aren't worth getting worked up about, and it's easy to ignore people. I was wrong. It took a long time for me to figure out that I was wrong, not just for other people, but for myself as well. It took me much longer to walk away from Usenet governance for good because the environment was too toxic. It remains one of the best decisions I have ever made in my life. It was the best bit of self-care that I ever did. I learned from that experience, and earlier this year, I walked away from a job for related reasons. I enjoyed the work, the job was much easier than the job that I have now, and I had a lot of time to work on free software and on Debian, but the emotional environment was toxic. (It was not as openly abusive, but it was an environment of disrespect, hierarchical dominance games, fear, blame, and emotional blackmail.) As a result, I've had to shift priorities considerably, but I'm a much happier person. It's worth having less time for things that I was previously enjoying to not to have to deal with an emotionally negative and confrontational environment. Life is too short, and I have the luxury of having choices. Both of those incidents taught me that it's very easy for me to leave that sort of situation to fester for too long, and that I underestimate how much of an improvement it is for my quality of life to walk away from abusive and negative emotional situations. I am belatedly learning how to be more ready and willing to do this. I very much understand the people who are concerned with ensuring there is space for strongly-worded opinions and heartfelt anger. But we have to draw a line, and that line needs to rule out emotional abuse of people in our community even in the name of passionate polemics about something that's important. We have to enforce that line, and if that means ejecting people from our community, that's what we have to do. Because, if we don't, we're also ejecting people from our community: the quiet people, the people who are just trying to get work done, or the people who have had past experience with abusive environments and understand the need to bail when an environment starts going in that direction. I'm not going to put up with the sort of environment I put up with when doing Big Eight newsgroup creation. I'm not saying this as some sort of threat -- I'm saying this to try to be very clear that not standing up for the members of our community and not supporting each other against abuse and emotional attacks also has consequences, and will destroy that community for a lot of us. I'm saying that I am not interested in living in an environment of fear and blame. And one should never underestimate the human power of giving people space and community in which they can be comfortable, relaxed, and truly happy. Walking the line between this stance and the "tone argument," in which people who are being abused or disenfranchised are attacked for being angry, is very difficult. There are some helpful rules of thumb, such as distinguishing between punching up and punching down, but those rules of thumb can fail or be distorted, as the SF community is learning. It's important that people be able to express anger. It's also important that people be able to name names and identify specific behaviors that they believe are worthy of that anger. But when that anger escalates into attacks, there is a real danger that passionate righteousness turns into passionate abusiveness, a danger of losing the sense of community in our own sense of righteousness. And that's not something we can or should accept. It's going to take a lot of hard work, a lot of open conversation, and a lot of empathy and care to find that line. There are many things in the world right now that should provoke anger, and with that anger comes power for good. But with that anger can also come a destructive blindness. The anger I want is the anger that drives us to change the world together, the anger that leads to confronting others with a reflection of their own better natures and challenging them to become better, more compassionate people. The anger that leads a man to feed the homeless in the true meaning of civil disobedience. Not the anger that crushes our enemies.