Philipp is a Debian developer since 2005 and a member of the release team since 2008. Since he took the responsibility of Stable Release Manager, the process has evolved for the best. I asked him to explain how the release team decides what s fit for stable or not. His work on the buildd infrastructure is also admirable but I ll let him describe that. My questions are in bold, the rest is by Philipp. Who are you? I m a 24 year old Computer Science student, living in Karlsruhe, Germany. As a student assistant I m currently in two jobs: one is taking care of getting our university IPv6 network in shape, or rather generally getting fringe technologies into the network. The second is taking care of a s390x machine in the basement which my faculty got sponsored recently. In my spare time I tend my Debian duties and I m active in the student council (Fachschaft) as a sys-admin, software developer and until recently as treasurer. I got accepted as a Debian Developer in 2005. I m only really active since I was invited to join the Release Team in early 2008 after I contributed rewrites of some scripts that got lost in a disk crash of ftp-master. In late 2008 I also took on wanna-build/buildd duties. What s your notable achievement within Debian? For one I worked on the deployment of a single buildd/sbuild combination over all of our buildds and I rebased it on the sbuild in the archive several times already. All buildds basically look the same on all architectures, with only few variations. The chroots are now also created in a mostly predictable manner. Then we finally got build autosigning after years of constant poking. However the policy decision to allow it was made by the ftp-masters anyway, for which I m grateful, as it eases the workload of the buildd maintainers, the Security Team and the Release Team quite a bit. On the release side there s the integration of volatile into the proper structures of Debian. But there I m guilty for choosing the bad name squeeze-updates is, in comparision with security s squeeze/updates. Let s see if we can improve that for wheezy. The policy for stable updates have changed over time. Can you summarize what kind of updates are allowed nowadays? All the changes that were made to the policy were driven by the aim to keep stable (and to some lesser degree oldstable) usable throughout its lifetime. I have to admit that we got slightly more liberal in what we accept since I took over. The previous stable update policy included the fixes of critical bugs that break the system in interesting ways and security fixes. We also opened up the possibility of including important fixes for annoying bugs on a case-by-case basis. The whole don t update that much part of the stable release management is rooted in let s don t change the behaviour of a running system and let s have as few regressions as possible . We currently try to counter that with a review process that only allows self-contained fixes that were tested in unstable first, if applicable. In the future I d also like to have a feedback process that includes the users of the packages to report problems more early. In fact that s also why we now send calls for testing to debian-stable-announce one week in advance (see this mail as an example). So stable is updated through point releases that happen roughly every two months for stable and roughly every four for oldstable. They are accompanied by announcements and new CD/DVD sets. To be able to push some updates with less delay to our users and to avoid that they have to pick them from proposed-updates, there is stable-updates. The current policy for this suite is available in this post on debian-devel-announce. It boils down to everything urgent like tzdata, regression fixes and volatile packages. We noticed that some packages in stable just weren t useful anymore when they got updated through volatile. Hence those are folded into stable, too. We also relaxed the rules a bit so that leaf packages like clive, that rely on external websites not to change their URLs, can be updated too. If somebody wonders what happened to the and a half releases Those were intended to mark the inclusion of new hardware support (mostly by including a co-installable new kernel version). This kind of flag point release is thankfully no longer needed because our marvellous kernel team now backports certain hardware drivers to the kernel version in stable. They have some trouble soliciting test feedback for them, though. It would be cool if more people using stable could respond to their calls for testing. What are your plans for Debian Wheezy? Luckily the wanna-build/buildd side isn t much dependent on release cycles. The stable release management also just takes care of what gets dumped on them by the testing RMs. The near-term goals are certainly:

• getting d-i to use some development process in the archive that s compatible with the normal flow of packages into testing and
• hopefully getting wanna-build to use a sane SQL layout and hence better performance

Apart from that my work is mainly squashing the bugs on buildd.debian.org for the wanna-build part, so if you want something fixed, you need to report it, I m afraid. You have several roles within Debian, in particular stable release manager and member of the wanna-build team. Which role do you enjoy more and why? So the regular duties of the SRM, apart from setting up policies, are reviewing requests for uploads to proposed-updates, accepting them, chasing builds and scheduling point releases. It s mainly steady work. As for the Release Team it s working in a fabulous team where everyone s doing an awesome job. For me the wanna-build role is holding the things together and fixing up stuff that breaks while the world continues to evolve. And occassionally taking a stab at the ftp-masters. So rather different. My heart is probably siding with the buildd side because it s infrastructure but release work is fun, too. What s the biggest problem of Debian? Mainly that we re not quick in picking up new technologies and that we got slow on innovation. Distro-wide changes are usually a very big effort to coordinate and to finally complete. I guess people should be able to push fixes for release goals more eagerly into the archive. Also it seems to me that many DDs are actually disengaging from the release process, especially during the freeze but also before, which makes me a bit sad. However I m still not sure how we could counter that. As we re all volunteers you can t suddenly make others love the idea of releasing something together, I guess. Do you have wishes for Debian Wheezy? It s getting old, but there s certainly multiarch. Also a usable Python 3 is something I d really appreciate. Is there someone in Debian that you admire for their contributions? Peter Palfrader did an awesome job of getting a nicely working team together for DSA and got many tasks as automated as they are now. It s a pleasure to work with them and setting up a new buildd is, for example, a real breeze. He also developed a sane archive snapshot service, kudos for that.

---

Thank you to Philipp for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

I doubt I have ever read a book that had as significant an impact on me, and my act of reading it had on others, as this one. Conversations like this were frequent: Someone, upon seeing me reading my Kindle, would ask what I am reading. War and Peace. Oh. . . uhm, wow. Yeah, it s great. I m reading it for fun. Uhm, OK then, see you later. . . It seems to be so revered, and also so loathed, that I had to read it. At 1400 pages, it took me 8 months to finish, though I read several other entire books in that time. I feel rather unequal to the task of expressing how this book impacted me, let alone a review of it. And nonetheless, I also feel I would be remiss if I let it go past saying nothing. I was struck by so many things as I read War and Peace. Some of them I won t mention here and hope to turn into their own blog posts. Of the others, I felt I gained some sense of how the nobility and serfs in Russia (and, to a certain extent, Europe) thought about life, their position, and how things ran. Being a modern Kansan, this thought process was not familiar to me, and though I head read about it in history texts before, felt far more informed having read it in Tolstoy s novel. Although much of the novel centers around Napoleon s invasion of Russia in 1812, the work as a whole spans nearly two decades of time. Tolstoy s characters aren t static; they change over time. Some, yes, die; others go through hardships and triumphs that change them to their core. It evoked a feeling of nostalgia in me at times for the younger, childlike Natasha who was so full of simple delight in life. But then, a thousand pages later, the older Pierre finally was able to find simple delight in life too. Sometimes I have missed on the simple joy of being, and Jacob or Oliver or Terah remind me of that. Today Oliver and I read a book together, one that we read often, and we discovered an illustration of a tiny worm we had never noticed before. And the worm had a red hat ( hat is one of Oliver s favorite words right now.) The happy laughter as he pointed at the tiny hat, saying hat over and over, reminds me that sometimes children know how to live better than adults. Jacob later asked me how my day was, and I told him how I read a book on my Kindle, where I sat, and how I even read it lying down on the couch for a bit. At that he too laughed. As with some other wonderful, engrossing books, I was sad to reach the end of this one. I felt as if I was leaving a conversation early; fictional characters, yes, but their story wasn t over. And really, that was part of Tolstoy s point: things don t happen in isolation, and stories don t have clearly-defined start and end points. The novel touched on politics, religion, philosophy, free will, and just about every topic imaginable. It is, really, unfair to call it a just a novel. Here are some random quotes from the book, which I highlighted:

his heart was now overflowing with love, and by loving people without cause he discovered indubitable causes for loving them. How often we sin, how much we deceive, and all for what? All will end in death, all! A pleasant humming and whistling of bullets were often heard. Looking into Napoleon s eyes Prince Andrew thought of the insignificance of greatness, the unimportance of life which no one could understand, and the still greater unimportance of death, the meaning of which no one alive could understand or explain. If there is a God and future life, there is truth and good, and man s highest happiness consists in striving to attain them. We must live, we must love, and we must believe that we live not only today on this scrap of earth, but have lived and shall live forever, there, in the Whole, said Pierre, and he pointed to the sky. Prince Andrew stood leaning on the railing of the raft listening to Pierre, and he gazed with his eyes fixed on the red reflection of the sun gleaming on the blue waters. There was perfect stillness. Pierre became silent. The raft had long since stopped and only the waves of the current beat softly against it below. Prince Andrew felt as if the sound of the waves kept up a refrain to Pierre s words, whispering: It is true, believe it. He sighed, and glanced with a radiant, childlike, tender look at Pierre s face, flushed and rapturous, but yet shy before his superior friend. In Natasha Prince Andrew was conscious of a strange world completely alien to him and brimful of joys unknown to him, a different world, that in the Otradnoe avenue and at the window that moonlight night had already begun to disconcert him. Now this world disconcerted him no longer and was no longer alien to him, but he himself having entered it found in it a new enjoyment. All the kings, except the Chinese, wear military uniforms, and he who kills most people receives the highest rewards. But what is war? What is needed for success in warfare? What are the habits of the military? The aim of war is murder; the methods of war are spying, treachery, and their encouragement, the ruin of a country s inhabitants, robbing them or stealing to provision the army, and fraud and falsehood termed military craft. The habits of the military class are the absence of freedom, that is, discipline, idleness, ignorance, cruelty, debauchery, and drunkenness. And in spite of all this it is the highest class, respected by everyone. From the moment Pierre had witnessed those terrible murders committed by men who did not wish to commit them, it was as if the mainspring of his life, on which everything depended and which made everything appear alive, had suddenly been wrenched out and everything had collapsed into a heap of meaningless rubbish. Though he did not acknowledge it to himself, his faith in the right ordering of the universe, in humanity, in his own soul, and in God, had been destroyed. He had experienced this before, but never so strongly as now. When similar doubts had assailed him before, they had been the result of his own wrongdoing, and at the bottom of his heart he had felt that relief from his despair and from those doubts was to be found within himself. But now he felt that the universe had crumbled before his eyes and only meaningless ruins remained, and this not by any fault of his own. He felt that it was not in his power to regain faith in the meaning of life. When Princess Mary began to cry, he understood that she was crying at the thought that little Nicholas would be left without a father. With a great effort he tried to return to life and to see things from their point of view. Yes, to them it must seem sad! he thought. But how simple it is. The fowls of the air sow not, neither do they reap, yet your Father feedeth them, he said to himself and wished to say to Princess Mary; but no, they will take it their own way, they won t understand! They can t understand that all those feelings they prize so all our feelings, all those ideas that seem so important to us, are unnecessary. We cannot understand one another, and he remained silent. Love hinders death. Love is life. All, everything that I understand, I understand only because I love. Everything is, everything exists, only because I love. Everything is united by it alone. Love is God, and to die means that I, a particle of love, shall return to the general and eternal source. These thoughts seemed to him comforting. People speak of misfortunes and sufferings, remarked Pierre, but if at this moment I were asked: Would you rather be what you were before you were taken prisoner, or go through all this again? then for heaven s sake let me again have captivity and horseflesh! We imagine that when we are thrown out of our usual ruts all is lost, but it is only then that what is new and good begins. While there is life there is happiness. There is much, much before us. I say this to you, he added, turning to Natasha. During that twenty-year period an immense number of fields were left untilled, houses were burned, trade changed its direction, millions of men migrated, were impoverished, or were enriched, and millions of Christian men professing the law of love of their fellows slew one another. What does all this mean? Why did it happen? What made those people burn houses and slay their fellow men? What were the causes of these events? What force made men act so? These are the instinctive, plain, and most legitimate questions humanity asks itself when it encounters the monuments and tradition of that period.

This week I finally used my packaging tutorial slides myself, a few days after Phil Hands used them at a UKUUG event. The tutorial is now available as a Debian package (in Debian unstable) named packaging-tutorial, and I ve talked to debian-doc@ about linking it from appropriate places. It s also hosted on collab-maint now, so don t hesitate to contribute. Links :

• Latest version (PDF)
• Git repo

Today I was baptized and joined the Mennonite Church. I imagine this might surprise some of you for various reasons, so let me provide a bit of background. I ve had a lot of people, both in person and in comments responding to my blog post, express surprise with statements I have made. The view of Christianity that many people have is of a group that devalues scientific inquiry and places a lot of emphasis on things like opposition to gay marriage, evolution, and abortion, and enjoys political leaders that say bring it on. While I know some Christians that fall into that mold, there are quite a few that don t as well. Some churches, such as the one we attend, have a surprisingly diverse set of people and yet still function and get along well. Today they accepted me with joy. Nobody was concerned that I started my statement with a reference to ancient Greek philosophy, wound up suggesting that the church ought to make sure to make illegal immigrants, gays and lesbians, and prostitutes feel welcome, and embraced both religion and scientific inquiry, feeling them complimentary. Mennonites practice adult baptism rather than infant baptism. A traditional age for people to be baptized is during high school, though emphasis is placed more on the individual than their age, so it s not unheard-of for someone to do so a bit later in life as I have. Part of the baptism involves the candidate sharing their faith story. These are typically intensely personal, widely varied, heartfelt, and honest. Some people s stories involve struggles with depression, physical disabilities, or the place of religion in their lives, while others reflect little struggle at all. Mine involves letting go of a lot of things, and also seeing some things, such as serious intellectual inquiry or existential questions about God (such as is there a god? ), as a positive rather than a negative feature of a Christian life. But it also involves a recognition and deep respect for those that don t approach things in this way. Though given publicly in a church, baptism testimonies are rarely published or shared more broadly. But I m going to share mine here. I have edited it only very lightly to remove a few local references that wouldn t make sense out of the context of this community. This was delivered in front of a rather different audience than is likely to be reading this post, so if you have questions, do feel free to ask in the comments. But before I begin, I just have to pass along a joke a friend told me: John, you picked quite a day for your baptism the day after the rapture. Baptism Testimony John Goerzen May 22, 2011 Those of you that know me well will probably not be surprised that I will begin my Christian baptism testimony with a story about an ancient Greek philosopher, and also touch on the philosophical nature of truth. These are key parts of my story. As legend goes, Socrates famously said, I know that I know nothing in other words, he believed that nothing could be known with absolute certainty. The Greek Oracle thought to be infallibly wise said that Socrates, the man that thought he knew nothing, was the wisest man in all Athens. An interesting paradox, and one that sheds light on my own religious story. My story involves coming to grips with the understanding that I know very little, that no person can ultimately know much about God, and finding a way to make peace with that situation. Growing up in this community, I thought I knew some things about faith and Christianity. At a certain age, it all seemed so simple. We took the Bible to be literally true. We marveled in Sunday School at how the apostles could sometimes appear so blind. And, modeled both implicitly and explicitly, was this notion: the stronger our faith, the fewer inner questions or doubt we have about the nature of God, the literal accuracy of the entire Bible, or our relationship to God. Those I perceived held up as examples never seemed to question any of these things, and showed outwardly, at least complete certainty about them. Moreover, holding certain intellectual beliefs was key to Christian identity, and even more importantly, to eternal life. This model has quite obviously worked well for many people for many years. The good that has happened, and continues to happen, from people that have that kind of certainty is manifest all around us. And yet, it didn t seem to work out for me. I m not the kind of person that accepts a lot of things at face value. It is helpful to be able to examine and challenge ideas and even more helpful to have other people challenge my ideas. From well before I was in high school, I was questioning some things about the Bible, God, and religion in general. My thoughts ranged from the impact of evolution on religion to the apparently vengeful God of the Old Testament to the very existence of God. In the Christian context, I perceived having these questions as a personal failing, something that I ought to repress. The more I tried to repress them, the more troublesome they became. Why, for instance, should a loving merciful God decide whether to let us into heaven based on whether we hold certain intellectual beliefs? In high school, I participated in the catechism class here at this church, and was frustrated because it didn t tackle deeper meanings or the kinds of questions I had. I wasn t yet able to articulate all my thoughts and questions very well, and I probably had an overactive case of teenage cynicism. As a result, I didn t get baptized like most others my age did. As I learned more about the early history of Judaism and Christianity, I only found more reasons to question the model of faith I thought I had received the one in which Biblical literalism and a divine guarantee of sorts was key. More recently, I gradually became aware that the model of Christianity I had in mind was one of many views. Christians, Mennonites, and even this church are incredibly diverse groups, and in retrospect, I am surprised that it took me so long to realize this. Three major steps led me to baptism. The first step was the realization that, whatever our understanding of the literal accuracy of the Bible, literal truth is often inferior to metaphorical truth. As an example, many of us have read the works of Shakespeare. They are fictional, but the reason they have been revered for so many centuries is that they are true. They teach us things about ourselves and our world in a way that no history book can. By placing such an emphasis on literal truth in the Bible, I was missing out on the message right there for me. By concerning myself with creationism or evolution, I missed out on thinking about what the story in Genesis meant for the Jews, and what it could mean for me. Evolution ceased to be a threat to religion; it became simply a tool for learning about a different sort of truth than we get from religion. N. T. Wright mentions an incident that illustrates this point. A woman attending a religious conference asked the speaker, a prominent theologian, Is it true that the serpent in Genesis actually spoke like you and I speak? The theologian answered, It doesn t matter whether the serpent could speak. What matters is what the serpent said. The second step I took towards being baptized was realizing where the real core of Christianity lies. It s not some debate about Genesis, but rather the death to one s old self, and the rebirth and continual remaking of oneself in the example of Jesus. Given that, a lot of questions seem unimportant or even irrelevant. Good can be expressed in many ways, and if one person achieves a remarkably Christian life via a literal understanding of the Bible, and another via a more metaphorical reading, then it is my place only to affirm both and say that they both got it right. If we say that the task of remaking ourselves is like climbing a mountain, then what matters is not how we are climbing the mountain, but simply that we are climbing it. I used to equate faith with an intellectual belief. I have come to see that was a narrow view. Faith, to me now, is more about vision: do we see the world like Christ did? Where do our loyalties and our trust lie in God or in human institutions? What are our goals in life? We humans have failed to understand God, and probably always will. I too share in that incomplete understanding, but I have come to accept that it is OK. I know enough to know that I want my loyalty to lie in Jesus, to know what kind of vision of the world I want to have, and I have learned to accept that intellectual questions can even be a form of meditation, enlightenment, and prayer. The third step toward baptism was moving past my own shortcomings. For a long time, I thought I didn t believe the right things, didn t believe them strong enough, wasn t certain enough about God, didn t pray enough, didn t read enough, didn t understand enough, didn t love enough and ultimately, that I wasn t good enough. I request baptism today understanding that, despite the various imperfections I still have, and we all have, everyone is good enough and deserving of love and peace. God s love is for everyone. No exceptions! Following Jesus boils down to this: I too must be an agent of love and peace to everyone, without exception. My vision must be centered around the fact that we are to emulate the God that loves the entire world, sinners all, and therefore I should as well. I hope I can show others the kind of love that has been shown me. I hope, too, to share with this congregation and the global church in the vision of love. I hope that we can continually strive to re-focus on Christ s vision. As an example, we all know that many different viewpoints about whether homosexuality is sinful exist in Mennonite Church USA. These opinions are deeply held and personal for many, and have been discussed over and over and over. But ultimately, they aren t terribly relevant to the church s mission. The example of Jesus unites us all: he embraced everyone. He accepted criminals and prostitutes and showed them love and kindness. Our difficult task, which is also my difficult task, is to show this same love to absolutely everyone, regardless of our varying opinions about them and their conduct. The forgotten and repressed of our day perhaps criminals, homeless, Muslims, addicts, gays and lesbians, illegal immigrants, ethnic minorities, and still prostitutes deserve the love of Christ s church and all its members. My hope is that any one of the earth s 7 billion people could step through the doors of our church, or any church, and immediately feel Christ s love, and the unconditional, non-judgmental, welcome and love of Christ s followers, no matter what. This prayer from Ephesians 3 sums up my hope and my vision, for myself and everyone:

I pray that out of his glorious riches he may strengthen you with power through his Spirit in your inner being. I pray that Christ may dwell in your hearts through faith. And I pray that you, being rooted and established in love, may have power, together with all the Lord s people, to grasp how wide and long and high and deep is the love of Christ. And I pray that you will know this love that surpasses knowledge that you may be filled to the measure of all the fullness of God. (3.16-19)

IPv6 adoption is increasing, and along with it come a new set of behaviours and defaults that system administrators and users must learn and become familiar with. I was recently caught out by Linux s handling of IPv6 router advertisements (RAs) when forwarding is also enabled on the interface. It took me a while to figure out and searching for obvious terms (such as those in the first half of the title of this post) didn t immediately yield useful answers, so here is my attempt to help shed some light on the subject. By default Linux will ignore IPv6 RAs if the interface is configured to forward traffic. This is in line with RFC2462 which states that a device should be either a Host or a Router. If you re forwarding packets you re a router and you re therefore expected to be sending RAs, not receiving them. This policy does make a certain amount of sense but there are obviously situations where it can be useful to accept RAs and still forward packets over the interface[0]. The confusing part is that the Linux IPv6 stack allows the accept_ra sysctl to be set to 1 (enabled) at the same time as the forwarding sysctl is set to 1, yet all incoming RAs are ignored with no hint as to why. If you re not aware that the default behaviour is to ignore RAs when forwarding is enabled it looks very much like autoconfiguration has simply broken. The key piece of information is that makes everything as clear as mud is realising that the forwarding and accept_ra sysctl s are not simple boolean enabled/disabled flags like many of their brethren. There are instead three possible values for each, all clearly documented in sysctl.txt, when you take the time to read it. Ironically the documentation states the type of the values as BOOLEAN even though they re not at least it helped me to feel better about my hasty assumption that the sysctl s were boolean values.

accept_ra BOOLEAN
Accept Router Advertisements; autoconfigure using them. Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled. Functional default: enabled if local forwarding is disabled.
disabled if local forwarding is enabled.

The documentation for forwarding is similar, but much longer, so you can refer to the link above to see it. Conclusion: If you want to autoconfigure IPv6 addresses on an interface that you re also forwarding IPv6 traffic over, you need to set accept_ra to 2. No doubt there are more IPv6 quirks and defaults like this waiting to trap me in the future [0] Arguably you really don t want to be autoconfiguring addresses on your router ever, but that s a philosophical debate that isn t really relevant to this post.

I was invited to talk at the Mukthi 11.04 event hosted at the M. S. Ramaiah Institute of Technology. I talked about Free Software/Debian - Philosophy, Design, Merits. The focus was more on the philosophical aspects of why Free Software/Debian. The slides are available here.

Date for end of sponsored registrations for this years DebConf11 in Banja Luka was set for May 8th, today that date has officially been extended to May 19th. Now to answer your question on why are you extending sponsored registrations 12 hours before it ends here s the answer. Registrations are going fine, we have more then 300 attendees who registered so far, it is due to change in our monetary resources as sponsorship level has changed from one to another, and we ve be granted to welcome more people. But it is also to give some possible attendees more time and information, as I ve got a feeling a lot of people from this region and elsewhere have been lacking some even general information, and thus I d like to bring everything closer to everybody. Before anything, heading to our website might be a good start as we have immense amount of information up there. Since government of Republika Srpska is our greatest and main financial sponsor, local team has made a document for them in which we tried to explain most basic and crucial things from what DebCamp and DebConf is over logistical/statistical data to what we have planned for Fun and Free time, so checking out that document might be a good idea as well DebConf11 Plan and Program. Since that might be too much for somebody as the documents stretches to some ~30 pages, I ll try to give answers to most common/asked questions. Registrations Who should register? In plain English, everybody. Only people that don t need to register are people who will attend Debian day, please see Plan and Program section 5.3 for more information on Debian Day. If you want to attend any of the DebConf lectures/presentations/whatever you should register. Registrations will play great deal in this years DebConf as if you register you ll get accreditation with your name on it and what you re allowed to do. Whether you have sponsored food/accommodation and thus allowed to eat for free or that you can sleep in certain hotel, or whether you re allowed to the pools for free; also as we re planning to have tight security in our Venue, in order for you to even enter Venue building you ll need to have accreditation on you. So, if you re planning to do anything with DebConf please do register. What is DebCamp/should I attend DebCamp? Please refer to Plan and Program document it s all said at the end of page 15. Sponsorship After registrations this is next thing that is brought up and that is most unclear to most of you. You re able to request travel, accommodation and food sponsorship, what each of those means is pretty self elaborate. But the real question here might be, who is eligible to request sponsorship? Again, everybody. What are is the criterion for getting sponsorship? There really isn t a written rule who gets the sponsorship and who doesn t but if you have ever been involved or contributed in any sort of way to Debian, or even have contributed or have been involved in any open source projects you re more then welcome to apply for sponsorship. Furthermore, due to the funds that we have been granted from Government of Republika Srpska, I even encourage you to ask sponsorship, don t be intimidated and just do it Professional/Corporate This is category for those who are sent by their companies, and whose participation/attendance is sponsored by the same. Professional covers the price of actual costs of their visit, while the corporate is double that price, which is for those who besides paying the actual costs also want to contribute money and help Debian. Organized transport and getting to Banja Luka Now, for those who are flying to Banja Luka I personally told you to come to via Zagreb. Why did I do this, if Banja Luka has its own airport? I told you this because Zagreb is much larger airport and thus has many budget companies, meaning cheaper flights. Once the registrations are closed, based on your arrival/departure dates we ll be able to statistically predict how many of you will be coming to Zagreb on each date and each time as we re planning to have organized transport. This means that we ll send buses/shuttles to pick people up in Zagreb. Of course to have this organized we ll need to set up arrival/departure pages with all the information that s need for us to have this organized. Now, for those who want to come directly to Banja Luka airport this might be bit pricer then going via Zagreb, but not by much. I personally value my time and I even fly from Zagreb to Sarajevo Phil for example booked his flight just this morning from London via Ljubljanja to Banja Luka and it wasn t that much more expensive then Zagreb. Also worth noting is that Banja Luka might be limited for some destinations, but I for a fact know that there are flights coming from Zurich, Ljubljanja, Belgrade and so on. Maybe someone from Banja Luka could follow up on this one with more information. Questions? With this post I hope I have brought some of these topics closer to you and that I made some things clearer. If you have any questions, please feel free to leave your comments or email whatever you re concerned about to our mailing list on: debconf11-localteam@lists.debconf.org Further reading:
Gunnar Wolf Posts explaining DebConf

This is just a quick note to say: Next week, I am going to be at: My goals for the conference:

• On Day 3, participate in a panel called How to keep and make productive libre graphics projects?
• Talk about the success of the recent Build It events.
• Learn more about the world of free software graphics app development.
• Enjoy the opportunity to speak French.
• Say 'hi' to old friends like Jon Phillips.
• Give chocolate to Michael Terry for staying positive on a recent gimp-deve thread.

I'm going to arrive in Montreal at 6:30am on Tuesday on an overnight Greyhound bus from Boston. So another goal:

• Make it through Tuesday without embarrassingly falling asleep in public.

If you want to say hi to me during the conference, email me and make sure we meet up!

Curious about these shiny new things i keep hearing about, i set up a test desktop system using using systemd as the init system (yes, that means using systemd-sysv in place of sysvinit -- so i had to remove an essential package for this to work). A system-crippling bug was naturally the result of living on the bleeding edge, but fortunately it was resolved with a trivial patch. In all, i'm pretty happy with some of the things that systemd seems to get right. For example, native supervision of daemon processes, clean process states, elimination of initscript copy-paste-isms, and socket-based service initiation are all obvious, marked improvements over the existing sysvinit legacy cruft. But i'm a bit concerned about other parts. For example, all the above-mentioned features fit really well within a tightly-tuned, well-managed server. But systemd also appears to rely heavily on complex userland systems like dbus and policykit that would be much more at home on a typical desktop machine. I've never seen a well-managed server installation that warranted either policykit or dbus. Also, given the bug i ran into -- when PID 1 aborts due to a silly assertion, your system is well-and-truly horked. Shouldn't a lot more attention to detail be happening? I'd think that a "recover gracefully from failed assertions" approach would be the first thing to target for a would-be PID 1. I'm also concerned about the Linux-centricism of systemd. I understand that features like cgroups and reliance on the spiffiness of inotify are part of the appeal, but i also really don't want to see us stuck with only One Single Kernel as an option. The kFreeBSD folks (and the HURD folks) have done a lot of work to get us close to having some level of choice at this critical layer of infrastructure. It'd be good to see that possibility realized, to help us avoid the creeping monoculture. I worry that systemd's over-reliance on Linux-specific features is heading in the wrong direction. So my question is: why is this all being presented as a package deal? I'd be pretty happy if i could get just the "server-side" features without incurring the dbus/policykit/etc bloat. I already run servers with runit as pid 1 -- they're lean and quite nice, but runit doesn't have systemd's socket-based initiation (or the level of heavyweight backing that systemd seems to have picked up, for that matter). I understand that Lennart is resistant to UNIX's traditional "do one thing; do it well" philosophy. I can understand some of his reasoning, but i think he might be doing his work and his tools a disservice by taking it this far. Wouldn't systemd be better if it was clearer how to take advantage of parts of it without having to subscribe to the entire thing? Of course, i might be missing some nice ways that systemd can be effectively tuned and pared down. But i've read his blog posts about systemd and i haven't seen how to get some of the nice features without the parts i don't want. I'd love to be pointed to some explanations that show me how i'm wrong :)Tags: systemd

So how much wind energy can we realistically use? A paper (Earth System Dynamics, DOI: 10.5194/esd-2-1-2011) by Miller,Gans and Kleidon (MGK10) has generated a lot of controversy courtesy of a New Scientist review (See Climate Progress for a good rebuttal). They argue that the effective limit we can safely extract without (bad) climatic consequences is around 18--68 TW (we currently use 0.2 TW of wind power). This paper is a follow-on to Kleidons work on the thermodynamics of the climate, where he points out that the free energy is the important measure of what energy can be generated by renewables. The free energy of the atmosphere is on the scale of hundreds of TW, he argues, much less than the heat energy of ~10^5 TW that comes from the sun. He argues that not enough attention is paid to the free energy budget, and argues that from MEP theory that free energy flows through different geophysical processes are more important than people currently think: such energy and momentum flows then lead to faster depletion of gradients than people currently use in their models. Frequently we use "diffusive-like" approximations to stuff we can't explicitly handle,such as convection and eddies below the resolution of our computer models. That the free energy budget, and small-scale processes need more detailed study (such as the transfer of momentum and energy from wind to water), I agree. But paradoxically, MGK10's estimates based on diffusive processes are what gets it into trouble. The critiques (e.g. Jacobsen and Archer) seem to concentrate on the estimates for diffusive and other energy losses (eg. wake fields) and climatic consequences are very loose, and out by factors of 50-100. They also ignore the fact that using wind as a substitute for more destructive energy sources produces a net gain, climate-wise. Based on these numbers, the real limits on wind power are more limited by where we can realistically place turbines, and the use and availability of rare earth metals in turbine magnets (MW sized turbines use over a ton of neodynium each in magnets!) One of the focuses of research at ICHEC and Met Eireann is wind for wind power: this becomes increasingly important for Ireland as we have more energy production by wind. I've been recently involved in a European project Weather Intelligence for Renewable Energies on investigating weather and climate forecasting needs of wind energy. In our weather models, we are getting to finer and finer resolutions (down to 2-5 km operationally, but working on 1 km in research), but as yet do not take account of wind energy changes. Modelling the wake turbulence, etc. and other effects of turbines is a 'fluid dynamics' problem done by the wind turbine manufacturers, mostly, in order to lay out turbines in a farm efficiently; this is done on the timescale of metres and seconds, while on the other end of the spectrum work is done in climate research on the changes in potential winds to see if wind energy will change in a few decades. But little is done on 'weather' scales of kilometres, minutes and hours: it turns out there are wind patterns that we don't predict in our models (vortices, etc.; especially for offshore turbines) that affect wind energy production, but would be very useful for wind farm and electrical grid operators to know about. So we should think about adapting our weather models for these. Either way, it looks like more detailed work on the interactions between atmospheric dynamics and wind farms would be a good thing. Incidentally, whatever about the alarmist nature of the article, kudos to New Scientist for their linking to papers: they quoted the names of the journals (Earth System Dynamics,Philosophical Transactions of the Royal Society), but where the article was not yet published (or behind a paywall), linked to the Arxiv.org version. More could do this. Tags climate, energy, thermodynamics, science, wind, renewables

As mentioned on Phils blog, Debian buildd's have now capability of autosigning builds. Today when arriving home I was greeted by an empty feeling - There was no builds to sign. The long standing routine had come to an end.

Good system administrators constantly look how to replace themselves with scripts and automation. Bad ones build job security by owning manual processes than nobody else can master.

With signing now done by some code instead of us, I (and other buildd admins) have more time and energy to work on irregular tasks - upgrading chroots, helping developers with porting problems etc. Not to mention blogging and updating ones own packages to sid..

Meanwhile, there are still some issues needing solving - $HOME isn't available on all buildds, -volatile and binNMU's need still manual signing. Certainly not the smoothest update, but it is already making life easier.

• Ben Hutchings reported that older Lenny CDs do not actually install anymore. As we are still telling people that they don't need to throw away old CDs this was a tad disappointing to me. Got myself a 5.0.0 disc through jigdo and cdimage's fine snapshot service for packages that aren't actually in (old)stable anymore. Using a network mirror during installation is apparently the default (although you can decline it). Doing so will try to go to the security mirror and try to upgrade the base installation it just expanded from the debs on the CD. As the archive signing key changed recently, this leads to apt moaning about untrusted packages, which isn't actually exported to the debian-installer UI. The installation just hangs in "Select and install software" with a prompt being displayed on tty4. Mark Hymers agreed that it makes sense to switch the Release signature for lenny-security back to the old key for the time being and called for objections on debian-devel. Doing so should fix installation for oldstable users with old CDs again. In the future d-i should upgrade debian-archive-keyring first before the security archive's contacted and I've filed a bug report about that (#619751).
• Closed some old crufty bug reports on the pseudo package buildd.debian.org that were either already solved or easy to solve. (#607619, #602841, #586882, #520479, #507153, #605285)
• Scripted the generation of keys to get the initial batch of them done. 27 machine keys have been generated so far, with the exception of some machines that are currently down or lack entropy (like the kfreebsd-* ones which aren't fed by the keys). The keys are already activated on the archive side. s390, half of powerpc and some amd64 already run with autosigning turned on. armel will follow tomorrow thanks to Riku Voipio. We'll get more coverage soon, I bet.
• Fixed up retry as an answer to the build log. There are two possible actions that a buildd admin can do when he received a log: retry and give-back. The former will cause a build retry on the same buildd it was tried before. The latter will give it back to wanna-build to reschedule it. Due to the way retry is implemented you cannot retry binNMUs, though. There's #524547 filed against buildd about that. (There's still no support to schedule a build on a specific set of buildds neither.)
• Fixed up a typo in the wanna-build trigger for the main archive that caused double builds when we manual re-run it instead of being pushed by the archive.
• Thought about how to use Packages-arch-specific properly from WB::QD (our Perl-ish quinn-diff replacement). Currently the handling of annotations like "!linux-any" is broken because the logic does not account for architecture wildcards (besides of "any" which is special ). Luckily there's some sort of test suite, which I already adapted locally, but the code isn't really the best to read at the moment. So that's still on my to-do list to solve #603762.
• There's a post on arch:all autobuilding not happening just yet pending in the queue. I hope to get it out tomorrow or the day after.

Proposals for autosigning were floating around for quite some time. The most controversial parts were how we secure the machines that do the building (and in turn: how do we secure the key) and who's going to manage the keyring (because there are multiple teams involved; such discussions can indeed take quite a bit time).

What we've agreed upon now is as follows:

• All buildds with autosigned must be debian.org machines, which means that they are administrated by the Debian Sysadmins. This involves regular upgrades of the machine, firewalling and monitoring. They are all doing this already (kudos!), so there was no change needed.
• The machines must be restricted so that only a limited set of people may access it. That's done, it's just the buildd admins for the specific buildd and the global group builddadm (plus the admins and the local admin, of course).
• Every host has its own GPG key. Key generation locally on the buildds is eased by having the fine Entropy Key hooked up to provide entropy centrally and distributed to the debian.org machines. Private keys don't need to and must not leave the host. The keys are rotated every 120 days, expiry dates will be used to ensure that and to remind us when rotation is due. Sadly there is no HSM involved. Given the geographic dispersiveness of the Debian infrastructure that's not done easily. Some machines (like s390 racks) would also be unable to connect local hardware.
• The keys are restricted to specific architectures. They are not able to upload any source to the archive. However every binary on the specific architecture can be uploaded using the key, there are no further restrictions on package priorities or the like. They are maintained by the wanna-build admins on ftp-master by signing the armored public keys with their personal GPG keys (instructions available on the list). Thus a trust chain is established: who added or removed which key and when.
• We plan to suppress networking in the chroot soon. This will possibly be done with unshare(1) in util-linux, as soon as we sort out proper localhost networking. This was not deemed a blocker at this point.

Should you have thought we are gone, let me assure you - we are not. I just blog a bit later than I did the last days. Anyways, we did have a good day yesterday. Turns out that, when Ansgar said I don t know much Python so might not be able to do much he actually meant Just point me at problems, no matter how complicated, and I come up with the python code to fix them . And so we did point him at various problems and got lots of code. And we intend to continue this until Sunday. Yesterday Mark got his Packages/Sources tool so far that we are about ready to ditch the old things, even though he took time to finalize my generate-release changes too. Not to speak about that database changes I wrote about in my last entry, which he now seems to have finally wrapped his brain around in a way to get those done. Short cite: good god, this will overhaul about all our code and database handling . And thats where he is currently working on too. He did draw a plenty complicated thats how it works onto the flip chart, and now seems to dump his brain into some form of python code. I m curious about the result, lets see. Torsten fixed up the code that generated the Maintainers and Uploaders files. The old code was just plain silly and took about 15 minutes just for the Uploaders file. It is now doing both of them in less than two. Of course there had been lots of bugfixes and code enhances too, not really good to list in a blog like this. My work, besides getting a bit sick in the evening, consisted of writing shell scripts to enable us and wanna-build admins to handle the keys needed for the automated signing of packages build on DSA maintained buildds. I have those ready now, so we are able to start doing the autosign stuff today/tomorrow. Phil - well, did whatever buildd related stuff he has to. Different place, I dont see much of it, but he has a blog himself, look over there.

And here we are, with another day of work ahead. And another huge unchecked/dinstall run about to finish. Yesterday evening Ansgar and later on Phil turned up, so we are now 5 persons sitting here and mostly coding happily away. Mark continued trying to wrap his brain around the changes we need to properly support multiple archives, with different sets of rights attached to them. It is a complex topic giving lots of headache. Besides that he is on a very good way of letting us completly remove apt-ftparchive by importing all the data we need to write Packages/Sources files on our own. And even better, the same work we can use to rewrite our rm and cruft-report commands in a sane way, not parsing Packages files anymore. Torsten did help with various database issues around the Packages/Sources issue and continued working on importing all the source filenames into the database, so we can soon provide a Contents file for sources. My own work, besides writing blog entries and preparing meeting minutes, consists of a rewrite of the script generating our Release files, the old one just wasn t up to it anymore. Especially not as we are on our way of having more and more of our tools use parallel processing, to fully use the power our ftp-master host has. And when I am done with this I will be off to tackle the keyring maintenance part we will need to enable autosigning by buildds to work. Should get interesting, with the shit of an interface one usually finds to gpg Ansgar started out by working on changes to our NEW handling, something I started with the dpkg bug #619131 and he just finished our site of the NEW handling scripts. Which means that, as soon as the dpkg maintainers added the code on their side and support this field in the .dsc files, NEW handling for packages like linux-2.6 will be much smoother. He is now implementing version control constraints into our control-suite tool. Phil is working on wanna-build stuff. And while this is just a short overview of what we did, there is always lots of discussion and bugfixing going on. It is incredibly useful to have a team sitting in one room for some days.

...and me. I turned 40 today and on such a momentous occasion I should pause
to take stock of my life. Executive summary: it's not bad at all. Last week I completed 13 years of marriage to Jyoti who loves me and always
looks out for my best interest even during the times when I do not. I have two lovely children who are kind, intelligent, Dharmic, and (mostly :-)
well behaved. Of course I can't forget all my dear friends and family who gave me their
blessings and good wishes today and indeed every day. My health is better now than it was in my twenties. Since last year I've been
exercising on the treadmill regularly and taken a lot of junk out of my diet.
I've lost about two stones and while I won't be joining the Debian marathon
runners just yet, I can at least jog briskly without collapsing in a puddle of
sweat, heart palpitations and shame. Mentally, I've been taking college level courses in Maths in an effort to
relearn the things I didn't pay proper attention to the first time I was in
college. I completed National Novel Writing Month for the first time with a
60,000 word philosophical science fiction blockbuster that other people might
actually consider readable once I finish revising it. And I am still training
for the day when I shall be granted the spot on Jeopardy which is rightfully
mine. Financially, the last few years have not been good for many people but we are
holding our heads above water and even slowly moving forwards. This is the
year Consolidated Braincells Inc. my little corporate empire will take off I
hope. As I begin preparing for Chaitra Navaratri I feel it will be extra special
this year because all these good things that are happening to me are solely
due to Her grace and krpa. Last thing I wanted to mention is that a present I gave myself today was to
make a donation to the Red Cross to help the victims of the tsunami in Japan.
If you have had good fortune in your life and have not already done so won't
you consider doing the same? (or to any of the other reputable charities
engaged in disaster relief.) Our shastras say that dana is the best insurance
against accidental sins and the guarantor of good luck.

I spend too much time writing Emacs Lisp code these days. Unfortunately, the more I do the more I find new useful tools to improve my work-flow and save time for doing more Lisp. D'oh. I did not work on any big thing these last weeks, so I'm thinking it's a good time to talk about the various code and patches I sent to multiple Emacs packages. el-get el-get, a fabulous tool that installs and handles all the external Emacs packages I use. A friendly war started on the development list about autoloads handling. The discussion was overall pointless, since we had a very hard time to communicate our ideas, and we did not understand each others several times. In the end, el-get now supports autoload correctly and do not load automatically all your packages, improving the startup time, and using the Emacs way to do things. Which is always better, obviously. git-commit-mode

I've started to use git-commit-mode some times ago. I usually use git-commit with the -v option to see what I'm committing. I though it would be useful to color the diff with diff-mode, so I wrote a patch just to do that, which was merged today by Florian. magit

Some weeks ago, I decided to give a try to magit, and loved it. I am not always using it, but for basic operations it is very useful. But I really soon found some things I did not like and therefore send patches to enhance it. First, I've added a patch to honor status.showUntrackedFiles which I use in my home directory. In the mean time, I've also added a patch to allow adding an arbitrary file. Yesterday, I sent another pull request, not closed for now, which adds the possibility to visit files in another window from a diff file, and the support for add-change-log-entry directly from the displayed diff. Useful for these old projects still using ChangeLog files but accessible through git (hi Emacs & Gnus!). Gnus

Nothing remarkable, but I write a couple of fixes and enhancements to the Sieve manage mode, to the Gravatar code and cleaned-up some very very old code. Also added the possibility to set list-identifier as a group parameter. Org-mode

I spent most of my time working on my jd/agenda-format branch, which is soon to be merged. I've also just got developer access to the Org-mode patch work and repository, so I'll be able to break things even more! ;-) ERC

I fixed the bug that annoyed me for a long time. Now erc-track does not reset the last channel status on window visibility changes not made by the user.

At the Emdebian ARM sprint, cross-building experiments on a Multi-Arch base are going fairly well. It is looking like the hacks in dpkg-cross may finally be avoidable, possibly before Wheezy gets released. Elsewhere, debhelper has been updated to allow dh_strip and other tools to work directly with the binutils package from the cross-building toolchain and not to need binutils-multiarch any more. dpkg-cross has been updated to only Suggest binutils-multiarch, which makes room for more architectures to be covered by binutils-multiarch (which, therefore, will be getting quite a lot bigger quite soon).

Cross-building in Debian is therefore entering a period of transition and the old ways of dpkg-cross - and the tools it has spawned like apt-cross, xapt, pdebuild-cross and others - will be gradually side-lined and finally rendered obsolete. Like all transitions, there will be breakage, there will be pain, there will be things which don't cross-build now and which have no prospect of being fixed until the transition is deeply entrenched. There are packages which used to cross-build and which will stop cross-building and, again, won't be fixable for months. Sadly, Squeeze released with cross-building breakage too, due to changes within apt during the release freeze. A Lenny chroot is possibly the best place to do cross-building for now.

This is a major transition. It WILL break things. Badly and often.
What's more, just because we decide to implement stuff using one method now does not mean that the same method will even exist in a month or two.

In other words, if you've got a working cross-build chroot or installation currently and you absolutely need it to continue working leave it alone.

Don't go changing real packages to use the changes we're trying out!

If you enjoy fixing stuff, don't mind pain and fancy risking your system as I've been doing (unlinking /etc/, deleting /lib64 on amd64 or forcing package installation such that no shared libraries are accessible any longer) then you are:

1. insane
2. welcome to join the work

Check out the current state of things via the #emdebian channel on oftc.net and the very risky Emdebian multiarch SVN experiments along with the even more risky Emdebian Multiarch Mirror, courtesy of Steve McIntyre and Phil Hands.

The README in SVN is very clear - DON'T INSTALL THESE OUTSIDE A CHROOT and even if you do, don't come crying to me when it breaks your entire system (even when used inside a chroot).

No warranty, no guarantees, no promises, none of this is fit for any purpose whatsoever and we'll say when we finally have something which might actually be useful.

Reading job listings for any sort of IT job is depressing. It s been quite some time since I ve had to do that, but how many times have you seen something like this:

• 5 years of Java experience required.
• 3 years of Java experience with modules X, Y, Z required.
• 6 years of experience administering Linux machines running RHEL 4 on a Windows 2000 domain with 1500 clients in an educational setting preferred.

I could go on and on. As a job seeker, that sort of thing is fundamentally devaluing to someone who has strengths in being adaptable and quickly learning new tools, languages, or even entire environments. As an employer, it sends a message that you re not interested in more than a surface look at someone s strengths, and probably don t care to hire the best and the brightest. After all, would you turn away a rockstar programmer simply because he or she had been writing filesystem code in C the last 3 years instead of the latest whizbang Java web widget that will probably be obsolete in a year and unsupported in two? I am quite certain that there are plenty of managers that do. Even if you are a company large enough to have an entire team of people that do nothing but work on that whizbang app, don t you still want the best you can find, realizing that some of the best people to work on that app may not have even heard of it yet? (And that when the app goes obsolete in 5 years, you d rather not have to lay off a large team of single-skill people) Some of you may know that I work in IT at a manufacturing company. We have a small IT team here, about seven people, and are a heavy Debian shop. And we have a vacancy open up in our development/Linux admin group. I m the manager of that group, which is why I m thinking about this right now. We re too small for single-subject specialists to make sense, yet we re big enough to appreciate skill, experience, flexibility, and rigor. Consequently, when the occasion arises for me to look for new employees, I don t prepare a laundry list of things we use in-house and would like experience with. The list of almost-required things generally begins with Linux and ends with experienced , and has nothing else in between. In other words, I d like it if I don t have to explain to you what a symlink or a hardlink is, but I d be willing to do so if I think you d internalize it quickly. On the experienced side, it would be nice if you already have a well-developed sense of fear at running rm when you re root, or have designed a storage infrastructure for a network before, or are paranoid about security. But again, if people can pick up those traits on the job, we are usually still interested. If learning how to package up software for Debian, fix bugs in software you ve never seen in a language you ve never heard of, raise good questions about things you may not have lots of experience with, and write documentation for it all on a wiki sounds like fun, then that s probably the kind of person I want, even if you ve never used our particular tools before. If I were to judge based on the stuff I normally see in job postings, I guess you might conclude I m nuts. I don t think I am, but then again I m also the only person I know that formats his own resume in hand-crafted LaTeX. What do you all think? The next question is: how should one evaluate candidates given this sort of philosophy? I m not a fan of canned tests, or even whiteboard tests that tend to be some sort of canned topic that may test the applicant s specific knowledge base more than overall skill and flexibility. Similarly, as an applicant in years past, I ve struggled with how to present the I ve never used $LANGUAGE, but I know I could pick it up quickly and do it very well vibe. To certain people, that might sound like BS. To the more geeky managers, perhaps it sounds like what they want. We ve built a fairly diverse team on the back of this approach, and it s worked out well for us so far. I m interested to hear your thoughts. Oh, and if you d like to work for us, you should probably be sending me an email. No, I m not going to list the address here on this blog post. If you can t figure it out, I don t want to hear from you <grin>