Search Results: "bap"

13 June 2011

Christian Perrier: So, what happened with Kikithon?

I mentioned this briefly yesterday, but now I'll try to summarize the story of a great surprise and a big moment for me. All this started when my wife Elizabeth and my son Jean-Baptiste wanted to do something special for my 50th birthday. So, it indeed all started months ago, probably early March or something (I don't yet have all the details). Jean-Baptiste described this well on the web site, so I won't go again into details, but basically, this was about getting birthday wishes from my "free software family" in, as you might guess, as many languages as possible. Elizabeth brought the original idea and JB helped her by setting up the website and collecting e-mail addresses of people I usually work with: he grabbed addresses from PO files on Debian website, plus some in his own set of GPG signatures and here we go. And then he started poking dozens of you folks in order to get your wishes for this birthday. Gradually, contributions accumulated on the website, with many challenges for them: be sure to get as many people as possible, poking and re-poking all those FLOSS people who keep forgetting things... It seems that poking people is something that's probably in the Perrier's genes! And they were doing all this without me noticing. As usually in Debian, releasing on time is a no-no. So, it quickly turned out that having everything ready by April 2nd wouldn't be possible. So, their new goal was offering this to me on Pentecost Sunday, which was yesterday. And...here comes the gift. Aha, this looks like a photo album. Could it be a "50 years of Christian" album? But, EH, why is that pic of me, with the red Debconf5 tee-shirt (that features a world map) and a "bubulle" sign, in front of the book? But, EH EH EH, what the .... are doing these word by H0lger, then Fil, then Joey doing on the following pages? And only then, OMG, I discover the real gift they prepared. 106, often bilingual, wishes from 110 people (some were couples!). 18 postcards (one made of wood). 45 languages. One postcard with wishes from nearly every distro representatives at LinuxTag 2011. Dozens of photos from my friends all around the world. All this in a wonderful album. I can't tell what I said. Anyway, JB was shooting a video, so...we'll see. OK, I didn't cry...but it wasn't that far and emotion was really really intense. Guys, ladies, gentlemen, friends....it took me a while to realize what you contributed to. It took me the entire afternoon to realize the investment put by Elizabeth and JB (and JB's sisters support) into this. Yes, as many of you wrote, I have an awesome family and they really know how to share their love. I also have an awesome virtual family all around the world. Your words are wholeheartedly appreciated and some were indeed much much much appreciated. Of course, I'll have the book in Banja Luka so that you can see the result. I know (because JB and Elizabeth told me) that many of you were really awaiting to see how it would be received (yes, that includes you, in Germany, who I visited in early May!!!). Again, thank you so much for this incredible gift. Thank you Holger Levsen, Phil Hands, Joey Hess, Lior Kaplan, Martin Michlmayr, Alberto Gonzalez Iniesta, Kenshi "best friend" Muto, Praveen Arimbrathodiyil, Felipe Augusto van de Wiel, Ana Carolina Comandulli (5 postcards!), Stefano Zacchiroli (1st contribution received by JB, of course), Gunnar Wolf, Enriiiiiico Zini, Clytie Siddall, Frans Pop (by way of Clytie), Tenzin Dendup, Otavio Salvador, Neil McGovern, Konstantinos Margaritis, Luk Claes, Jonas Smedegaard, Pema Geyleg, Meike "sp tzle queen" Reichle, Alexander Reichle-Schmehl, Torsten Werner, "nette BSD" folks, CentOS Ralph and Brian, Fedora people, SUSE's Jan, Ubuntu's Lucia Tamara, Skolelinux' Paul, Rapha l Hertzog, Lars Wirzenius, Andrew McMillan (revenge in September!), Yasa Giridhar Appaji Nag (now I know my name in Telugu), Amaya Rodrigo, St phane Glondu, Martin Krafft, Jon "maddog" Hall (and God save the queen), Eddy Petri or, Daniel Nylander, Aiet Kolkhi, Andreas "die Katze geht in die K che, wunderbar" Tille, Paul "lets bend the elbow" Wise, Jordi "half-marathon in Banja Luka" Mallach, Steve "as ever-young as I am" Langasek, Obey Arthur Liu, YAMANE Hideki, Jaldhar H. Vyas, Vikram Vincent, Margarita "Bronx cross-country queen" Manterola, Patty Langasek, Aigars Mahinovs (finding a pic *with* you on it is tricky!), Thepittak Karoonboonyanan, Javier "nobody expects the Spanish inquisition" Fern ndez-Sanguino, Varun Hiremath, Moray Allan, David Moreno Garza, Ralf "marathon-man" Treinen, Arief S Fitrianto, Penny Leach, Adam D. Barrat, Wolfgang Martin Borgert, Christine "the mentee overtakes the mentor" Spang, Arjuna Rao Chevala, Gerfried "my best contradictor" Fuchs, Stefano Canepa, Samuel Thibault, Eloy "first samba maintainer" Par s, Josip Rodin, Daniel Kahn Gillmor, Steve McIntyre, Guntupalli Karunakar, Jano Gulja , Karolina Kali , Ben Hutchings, Matej Kova i , Khoem Sokhem, Lisandro "I have the longest name in this list" Dami n Nicanor P rez-Meyer, Amanpreet Singh Alam, H ctor Or n, Hans Nordhaugn, Ivan Mas r, Dr. Tirumurti Vasudevan, John "yes, Kansas is as flat as you can imagine" Goerzen, Jean-Baptiste "Piwet" Perrier, Elizabeth "I love you" Perrier, Peter Eisentraut, Jesus "enemy by nature" Climent, Peter Palfrader, Vasudev Kamath, Miroslav "Chicky" Ku e, Mart n Ferrari, Ollivier Robert, Jure uhalev, Yunqiang Su, Jonathan McDowell, Sampada Nakhare, Nayan Nakhare, Dirk "rendez-vous for Chicago marathon" Eddelbuettel, Elian Myftiu, Tim Retout, Giuseppe Sacco, Changwoo Ryu, Pedro Ribeoro, Miguel "oh no, not him again" Figueiredo, Ana Guerrero, Aur lien Jarno, Kumar Appaiah, Arangel Angov, Faidon Liambotis, Mehdi Dogguy, Andrew Lee, Russ Allbery, Bj rn Steensrud, Mathieu Parent, Davide Viti, Steinar H. Gunderson, Kurt Gramlich, Vanja Cvelbar, Adam Conrad, Armi Be irovi , Nattie Mayer-Hutchings, Joerg "dis shuld be REJECTed" Jaspert and Luca Capello. Let's say it gain:

Russell Coker: Evil Psychologists

Last year the Psychologist and Baptist minister George Rekers who is famous for anti-homosexuality pseudo-science was discovered to be hiring gay escorts from Rentboy.com. Lots of LULZ there. But the story didn t end there. It turns out that George Rekers did some research on a child who ended up committing suicide as an adult, and the circumstantial evidence suggests that George s actions are directly related to the suicide [1]. The Rentboy.com affair doesn t seem so funny now. The Box Turtle Bulletin has a series of articles about Kirk Andrew Murphy s suicide and the roles of George Rekers and Richard Green in all of this [2], the articles are well written and generally appear to be well researched I recommend reading the articles if you can stomach them (lots of nasty stuff is described). The section answering the question of who s responsible for the mistreatment of Kirk Andrew Murphy [3] where they describe the use of ABA (AKA the Lovaas Technique) is interesting. Ivar Lovaas worked with George Rekers in such research and published a paper with him. The term ABA gets an immediate hostile reaction in the Autism community, but until now I hadn t realised why so many people hate it so much. It seems that to some extent I made the classic mistake of misjudging the reports of Autistic people who are unable to present their case well (as opposed to the psychologists who can present any position very well even if it s utterly insane). In the past I had the impression that ABA wasn t inherently bad, it was just implemented in a bad way in some cases now it seems that ABA was designed in an evil way right from the start. There is one massive problem with the Box Turtle analysis, he says Behavioral analysts don t dig around much into people s feelings, fears, dreams, family relationships or childhood memories. Indeed, in cases like autism, Lovaas s specialty, those avenues of exploration would be irrelevant . It could be that Jim Burroway (the Box Turtle writer) is merely quoting someone else without attribution, but even so saying that the feelings, fears, and dreams of a group of people are irrelevant is just awful, a statement that denies the humanity of a group of people can t be quoted without further explanation. In his article about ABA Jim refers to childhood Autism as a condition for which there is no hope for interior change [4]. I m not sure if he s just saying that Autistic children are incapable of learning or whether it s all Autistic people, in either case it s nonsense in terms of science and nasty as well. Generally I expect that members of various minority groups will show more sympathy to each other than they receive from the general population. Jim s posts are a great disappointment. I understand that he would be rather stressed about the horrible things that George Rekers et al did, but even so he should be able to avoid that sort of thing. Jim is obviously a very talented writer and can do better. One might think that Jim s posts use the word Autism to refer only to the people who are non-verbal (or in other ways less capable than the huge number of Autistic people who work for companies like Google and IBM). But that s no excuse either. You can find blogs and essays written by non-verbal Autistic people that describe their experiences if you care to search for them. It s obvious that they are people too and deserve to be treated as people not objects. Abusing Autistic children to try and make them impersonate NT children is no less evil than abusing children who don t fit gender norms.

24 May 2011

Russell Coker: Are Assholes Essential to a Free Software Project?

What do Assholes do? Rusty just wrote a post titled If you didn t run code written by assholes, your machine wouldn t boot [1] about some of the anti-social tendencies demonstrated by programmers, including some that are implied to be fairly important. His post seems to imply that there are really great programmers who are anti-social and that we should just put up with it because of their great code. One of the problems with his post is that he doesn t define asshole . Holocaust deniers and all other Nazi supporters seem to clearly by assholes by any definition. People who have silly ideas about medicine and tell others seem to be merely misguided (although my dictionary gives stupid or irritating or ridiculous in the definition of asshole so technically they can meet the criteria). In the comments Rusty states that nuttiness is relative . While that is correct it doesn t seem to have much bearing on whether someone is an asshole. For example I know some very nice people who are utterly convinced by creationism. Is Anyone Essential to Free Software? Most projects have one person or several people in leadership positions, usually there seems to be a combination of project management and lead-programmer positions. Such people are obviously quite important to a project. But we have seen examples of people dying, being employed by Microsoft, retiring, relicensing the source in a bad way, and just losing interest without the project ceasing. It seems clear that in most cases when a project which has a significant amount of use has significant bugs and no maintainer then someone will step in. The cases where no-one takes over the project are often resolved by someone creating a competing project. If no-one takes over an abandoned Free Software project then it s a strong indication that the project wasn t particularly important anyway. I have no doubt that if any bug or missing feature made Linux systems stop booting then someone would fix it quite quickly. In a more general sense it seems that every time someone takes a position in a project that is of wide interest they are displacing someone else who might have done the job. When you volunteer to do significant work for a project you may be displacing someone who is more skillful than you this isn t necessarily a bad thing as there are plenty of other projects to work on, some of which require more skill. Growing More Programmers It seems to me that a large part of becoming a great programmer is facing great challenges. People who could be described as optimistic or arrogant will tend to take on more challenging tasks and therefore learn more. I m sure that there are a lot of people out there who have the potential to be great programmers apart from not taking on the challenging work, this seems to be an unfortunate waste of talent. Given a large enough population if someone leaves a senior position there should be someone else who can obtain the skills needed to take over. One advantage of this for Free Software development is that even if the best person to take on the challenge isn t living in the most convenient continent that won t be an obstacle, while with proprietary software development projects the teams are small and it s common that no-one else is capable of stepping up to a lead position. Another advantage is that when the lead developer leaves there are generally many candidates to replace them, all of whom can start work and be judged on the work that they do. I think that the best claims that can be made regarding essential people are not in regard to technical skill alone but to a combination of technical and people skills. Getting a group of programmers to work together is really hard but it s something that needs to be done for any significant project. Also the larger projects tend not to stand alone, being able to get changes included in other projects requires some skill. Ben Collins-Sussman and Brian Fitzpatrick gave an insightful talk at Google IO 2008 titled How to Protect Your Open Source Project From Poisonous People [2]. The first half of their talk is mostly about people who are misguided or difficult rather than what most people would consider poisonous and the second half is more about people who are actively poisonous and need to be removed. They advocate a community based on Politeness, Respect, Trust, and Humility. They describe in detail how the methods they advocate result in the members of their community being more productive, it seems obvious that those principles will lead to better career growth for people within the community and more friendly people wanting to join. When is being an Asshole OK? I once worked for a company that apparently had a team consisting solely of assholes. Apparently one asshole got promoted to management and after some internal transfers they ended up with all the assholes in the company on one team. I guess that when someone has negative interactions with everyone they won t notice the difference if they are put in a team where everyone is difficult. For a corporate environment that lacks a no jerks hiring policy this is probably a good way of improving productivity overall. I am not aware of any significant Free Software project that was comprised of mostly jerks although I have seen a few with dysfunctional environments that encourage the worst behavior from their members. The smaller Free Software projects have less need for people who can relate to other people. There are many useful Free Software projects which have only one developer, in most cases anyone can take the source code and use it without dealing with the author. But even for a single-developer project an asshole can cause some serious problems. One example I know of concerns a developer who had unclear licenses and started making legal threats in response to a request for a clear license. Another example is of a developer who released code that was designed to not work when one particular user compiled it and redistributed the binaries. Both of them caused some significant amounts of time to be wasted by people who were unfortunate enough to develop systems that interacted with the code in question, and even more time was wasted when some misguided people defended them in the inevitable flame-wars. Even for a project with only one developer it s still better for everyone if that developer isn t an asshole. One comment I ve seen related to this issue suggesting that some types of asshole behavior shouldn t be a problem an example that was cited is a colleague who cheats on a romantic partner. Jeremy Clyman (who is currently doing a Ph.D in Psychology) has written an interesting article about this for Psychology Today [3]. He reviews the movie The Dilemma which deals with someone catching their colleague s wife cheating. Jeremy analyses the psychological issues involved and how they can (among other things) impact the ability for such people to work. I once worked in an office where two married employees were very open about having an affair and we were all apparently expected to lie on their behalf if necessary, it really affected the quality of the working environment. Extreme Assholes There are lots of people involved in Free Software development who are difficult and many who are to some extent assholes. But some of them take being an asshole to the extreme, such as Holocaust deniers (an example which Rusty used). In the comments on his post the Westboro Baptist Church is also mentioned. It is possible to entirely disagree with someone on a contentious issue such as abortion but still be able to get along with them. But when someone supports a hate-based organisation such as the WBC or supports Nazis in any way then there will be many people who just can t tolerate them and no-one should be expected to tolerate such people. I have seen two instances where Free Software developers advocated pro-Nazi positions (one had an archive of neo-Nazi propaganda and the other claimed that Nazis were not responsible for the Holocaust). Neither of the pro-Nazi programmers was evicted for defending Nazis, but both of them ended up leaving the community in adverse ways after causing other damage in the mean time. I don t think it takes any great ability to predict the future to determine that someone who defends Nazis will eventually end up doing something that requires expulsion and drive away users and developers in the mean-time. There is no possibility that someone can support the Nazi or WBC ideology only when not associated with your project, it will affect all aspects of their life. When a Holocaust denier is allowed to be a member of a community it also sends out a message that members of the groups which were persecuted by Nazis aren t particularly welcome in the community. Helping Minor Assholes There are a lot of people who don t have malevolent aims but who unintentionally cause some difficulty (it seems that the truly malicious are a tiny minority). I don t think that excusing the bad things that they do on the basis of writing good code helps them in the long term. Many of the suggestions that Ben Collins-Sussman and Brian Fitzpatrick make seem likely to help people who don t want to be assholes and direct them towards positive involvement in the community. One trend that seems apparent is the non-linear response to certain types of bad behavior. There is often little difference in severity between something that gets almost no attention and something that results in a large and extremely hostile reaction. If someone persists in acting like an asshole for long enough it seems to be inevitable that they will eventually exceed some threshold for what is tolerated and get a very significant negative response. It would be good if things didn t need to get to that stage. I think that the most unfortunate aspect of Rusty s blog post is that most people will probably interpret it as encouragement to write better code as a way of getting a free pass for being an asshole. I know that this isn t what Rusty intended, but most people on the Internet don t know Rusty as well as I do. Conclusion Ben Collins-Sussman and Brian Fitzpatrick seem to have some of the best ideas for how to deal with these issues when you control a project, but most of us aren t in that position. Everyone can advocate better behavior. Extreme assholes need to be removed quickly and without a great debate about their contributions, freedom of speech, or other issues. Since considering this issue I ve been wondering about when one should avoid the lesser assholes and asshole-positive environments. People tend to adapt to their environment, so if you associate with assholes a lot then there s a good chance you will start to become like them. Is

23 May 2011

John Goerzen: Baptism

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)

13 May 2011

Pietro Abate: Eating you own dog food - mpm

After a bit of work, today I decided to start using mpm, the mancoosi package manager, to upgrade my laptop. My first use of it on a production system - until now I run all my experiments in throw-away virtual machines - and it works ! Not rocket science here. During the last month David Kalnischkies (of APT fame) visited our offices in Paris and together with zack worked out a communication protocol between apt-get and the mancoosi cudf solvers (EDSP). I guess somebody is going to announce all details about this endeavor soon. This cooperation enabled us to advance in the integration of apt-get and the mancoosi technology. Reusing the same protocol and backend I developed to translate the apt problem to cudf (and to call a suitable solver), I've re-wrote large part of mpm and added the possibility to generate the installation plan before calling dpkg and really installing the selected packages. Below notice the intermediate calls as Inject Model , Simulate, Compare Models . These are at the moment stubs that are going to call the simulation framework developed at mancoosi. The food :
abate@zed.fr:~/Projects/git-svn-repos/mpm$sudo ./mpm.py -c mpm.conf update
Reading package lists... Done
Building dependency tree
Reading state information... Done
Inject Model ...


abate@zed.fr:~/Projects/git-svn-repos/mpm$sudo ./mpm.py -c mpm.conf upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following new packages will be installed:
libtracker-client-0.8-0 libnet-ip-perl libio-socket-ssl-perl libasyncns0 libapr1
5 to install
Simulate
Proceed ? yes/[no]
yes
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: changelogs for zed
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: changelogs for zed
(Reading database ... 179534 files and directories currently installed.)
Preparing to replace libapr1 1.4.2-8 (using .../libapr1_1.4.4-1_amd64.deb) ...
Unpacking replacement libapr1 ...
Preparing to replace libasyncns0 0.8-1 (using .../libasyncns0_0.8-2_amd64.deb) ...
Unpacking replacement libasyncns0 ...
Preparing to replace libio-socket-ssl-perl 1.40-1 (using .../libio-socket-ssl-perl_1.43-1_all.deb) ...
Unpacking replacement libio-socket-ssl-perl ...
Preparing to replace libnet-ip-perl 1.25-2 (using .../libnet-ip-perl_1.25-3_all.deb) ...
Unpacking replacement libnet-ip-perl ...
Preparing to replace libtracker-client-0.8-0 0.8.17-2 (using .../libtracker-client-0.8-0_0.8.18-1_amd64.deb) ...
Unpacking replacement libtracker-client-0.8-0 ...
Processing triggers for man-db ...
Setting up libapr1 (1.4.4-1) ...
Setting up libasyncns0 (0.8-2) ...
Setting up libio-socket-ssl-perl (1.43-1) ...
Setting up libnet-ip-perl (1.25-3) ...
Setting up libtracker-client-0.8-0 (0.8.18-1) ...
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB

Total disk space freed by localepurge: 0 KiB

localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB

Total disk space freed by localepurge: 0 KiB

Inject Model ...
Compare Models ...
abate@zed.fr:~/Projects/git-svn-repos/mpm$
Reg the installation plan, this is an xml file that will be passed to a simulator developed by the university of L'Aquila to make sure that the installation script (well, a model of them), will not cause any problem during the installation. The format is a very simple xml file as follows :
<selectionStates>
<selectionState type="Install">
<param name="package" value="libapr1" />
<param name="version" value="1.4.4-1" />
<param name="architecture" value="amd64" />
</selectionState>
<selectionState type="Install">
<param name="package" value="libasyncns0" />
<param name="version" value="0.8-2" />
<param name="architecture" value="amd64" />
</selectionState>
<selectionState type="Install">
<param name="package" value="libio-socket-ssl-perl" />
<param name="version" value="1.43-1" />
<param name="architecture" value="all" />
</selectionState>
[...]
Soon APT will ship a patch to use the very same infrastructure of mpm (yeii !!!). This will on one hand make mpm useless as package manager on its own. It is a simple hack in python and I never tough to compete with its big brothers. On the other hand I think it will stand as a nice workbench to experiment with new ideas, to prototype new features and to make it easier for poeple that are not c++ experts to play with the APT library (thanks to python-apt) in a semi structured environment. The code is in the mancoosi svn if you want to have a look.

Pietro Abate: Eating my own dog food - mpm

After a bit of work, today I decided to start using mpm, the mancoosi package manager, to upgrade my laptop. My first use of it on a production system - until now I run all my experiments in throw-away virtual machines - and it works ! Not rocket science here. During the last month David Kalnischkies (of APT fame) visited our offices in Paris and together with zack worked out a communication protocol between apt-get and the mancoosi cudf solvers (EDSP). I guess somebody is going to announce all details about this endeavor soon. This cooperation enabled us to advance in the integration of apt-get and the mancoosi technology. Reusing the same protocol, and backend I developed to translate the apt problem to cudf (and to call a suitable solver), I've re-wrote large part of mpm and added the possibility to generate the installation plan before calling dpkg and really installing the selected packages. Below notice the intermediate calls as Inject Model , Simulate, Compare Models . These are at the moment stubs that are going to call the simulation framework developed at mancoosi. The food :
abate@zed.fr:~/Projects/git-svn-repos/mpm$sudo ./mpm.py -c mpm.conf update
Reading package lists... Done
Building dependency tree
Reading state information... Done
Inject Model ...


abate@zed.fr:~/Projects/git-svn-repos/mpm$sudo ./mpm.py -c mpm.conf upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following new packages will be installed:
libtracker-client-0.8-0 libnet-ip-perl libio-socket-ssl-perl libasyncns0 libapr1
5 to install
Simulate
Proceed ? yes/[no]
yes
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: changelogs for zed
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: changelogs for zed
(Reading database ... 179534 files and directories currently installed.)
Preparing to replace libapr1 1.4.2-8 (using .../libapr1_1.4.4-1_amd64.deb) ...
Unpacking replacement libapr1 ...
Preparing to replace libasyncns0 0.8-1 (using .../libasyncns0_0.8-2_amd64.deb) ...
Unpacking replacement libasyncns0 ...
Preparing to replace libio-socket-ssl-perl 1.40-1 (using .../libio-socket-ssl-perl_1.43-1_all.deb) ...
Unpacking replacement libio-socket-ssl-perl ...
Preparing to replace libnet-ip-perl 1.25-2 (using .../libnet-ip-perl_1.25-3_all.deb) ...
Unpacking replacement libnet-ip-perl ...
Preparing to replace libtracker-client-0.8-0 0.8.17-2 (using .../libtracker-client-0.8-0_0.8.18-1_amd64.deb) ...
Unpacking replacement libtracker-client-0.8-0 ...
Processing triggers for man-db ...
Setting up libapr1 (1.4.4-1) ...
Setting up libasyncns0 (0.8-2) ...
Setting up libio-socket-ssl-perl (1.43-1) ...
Setting up libnet-ip-perl (1.25-3) ...
Setting up libtracker-client-0.8-0 (0.8.18-1) ...
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB

Total disk space freed by localepurge: 0 KiB

localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB

Total disk space freed by localepurge: 0 KiB

Inject Model ...
Compare Models ...
abate@zed.fr:~/Projects/git-svn-repos/mpm$
Reg the installation plan, this is an xml file that will be passed to a simulator developed by the university of L'Aquila to make sure that the installation script (well, a model of them), will not cause any problem during the installation. The format is a very simple xml file as follows :
<selectionStates>
<selectionState type="Install">
<param name="package" value="libapr1" />
<param name="version" value="1.4.4-1" />
<param name="architecture" value="amd64" />
</selectionState>
<selectionState type="Install">
<param name="package" value="libasyncns0" />
<param name="version" value="0.8-2" />
<param name="architecture" value="amd64" />
</selectionState>
<selectionState type="Install">
<param name="package" value="libio-socket-ssl-perl" />
<param name="version" value="1.43-1" />
<param name="architecture" value="all" />
</selectionState>
[...]
Soon APT will ship a patch to use the very same infrastructure of mpm (yeii !!!). This will on one hand make mpm useless as package manager on its own. It is a simple hack in python and I never tough to compete with its big brothers. On the other hand I think it will stand as a nice workbench to experiment with new ideas, to prototype new features and to make it easier for poeple that are not c++ experts to play with the APT library (thanks to python-apt) in a semi structured environment. The code is in the mancoosi svn if you want to have a look.

3 May 2011

Christoph Berg: Marriage and Baptism

29. April 2011

25 April 2011

Obey Arthur Liu: Welcome to our 2011 Debian Google Summer of Code students!

I d like to extend a warm welcome to our new batch of students selected for the 2011 Debian Google Summer of Code! They should soon be posting on Debian Planet and you re welcome to come talk to them on #debian-soc on irc.debian.org Further details will be posted in the coming days to our wiki: http://wiki.debian.org/gsoc Automated Multi-Arch Cross-Building and Bootstrapping aka autocrossbuild , by Gustavo Prado Alkmim, mentored by Wookey
Enable easy and automated setup of cross-platform automated build systems and bootstrapping for QA in the Multi-Arch era. This involves the creation of multi-stage bootstrap build sequencing tools and a reliable automated multi-arch cross-builder. APT/Dpkg Transaction Ordering for Safety and Performance aka aptordering , by Chris Baines, mentored by Michael Vogt
The ordering code in libapt is responsible for ordering the unpacking/configuration of debs so as to ensure dependencies are satisfied etc. Currently it organizes the ordering into big batches. This project further implements an ordering satisfying more constrains such as minimal amounts of dpkg invocations , minimal amount of broken packages at any point . DebDelta APT Native Integration aka debdelta , by Ishan Jayawardena, mentored by Michael Vogt
Improve user experience of APT and its front-ends by speeding up the upgrade process. This provides a better framework for unified handling of debdelta and future APT improvements such as parallelism. Support for stable and security ugprades as well as multiple APT related libraries is expected. Dpkg Declarative Diversions aka declarativediversions , by Sam Dunne, mentored by Steve Langasek
The dpkg-divert command should be replaced with a new control file with a declarative syntax which Dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions. Backend Tools and Infrastructure for DEX aka dextools , by Nathan Handler, mentored by Matt Zimmerman
EX is a new program designed to help improve Debian and its derivatives by merging in changes made downstream and encouraging discussions between the various projects. As this is a new project, most of the infrastructure does not exist (or is rather hackish and incomplete). This project will create the necessary backend tools and infrastructure so that all Debian derivatives can easily make use of the DEX project. Jigsaw Modularized Java in Debian aka jigsaw , by Guillaume Mazoyer, mentored by Tom Marble
The Java Development Kit (JDK) is a big monolithic software tool: many of its features are only useful in limited areas (GUI toolkits are useless for a web server). This project will bring the Jigsaw modular JDK to Debian, helping performance (start-up, size, etc) but also the dependency resolution (to match Debian packaging). Some work exists upstream does not fit with Debian. This project will package the current development version of Jigsaw, update Debian Java Policy, and create the necessary packaging tools for software depending on it. Python Multi-Build for Python Extensions Packaging aka pythonmultibuild , by Mesutcan Kurt, mentored by Piotr O arowski
This project creates a tool to build Python extensions for all Python versions supported by Debian at the time. The project should detect the upstream build system and testing frameworks and use them. It will be interfaced with CDBS and the dh sequencer, replacing their Python snippets. Debian Teams Activity Metrics aka teammetrics , by Sukhbir Singh, mentored by Andreas Tille
This project will gauge the performance of teams in Debian by measuring metrics such as: postings on relevant mailing lists, package upload records from the Ultimate Debian Database and commit statistics from project repositories The information gathered will help in evaluating team performance by measuring how people in a team are working together. An interface to access this information easily will also be developed. Compute Clusters Integration for Debian Development and Building aka computeclusters , by Rudy Godoy, mentored by Steffen M ller
The project s main goal is to enable developers to easily use compute clusters (Eucalyptus, OpenStack ) as environments for arch-specific development by providing a set of tools they can use to setup and run an extended platform for their development, testing and building tasks. Good luck to everyone!

21 March 2011

Steve Kemp: New software always causes surprises

I recently deployed my node.js proxy server, removing all traces of Apache2 from my main server. During the course of this transition I discovered:
Bugs in my code
Not unexpected, in all honesty. There were two main issues; the first was relating to how I handled the 304 response, the second was relating to how I performed rewrites for my mercurial repository vhost.
Bugs in node.js
Given how new node.js is there wasn't a huge surprise here either, although I thought I'd been good testing against 0.2.x. As it turned out I needed to run the more recent 0.4.x to avoid a couple of issues: In short I have a backported node.js package for Squeeze which is almost worthless. I'll update it in the near future. For the moment: 
cd node-v0.4.3/
./configure --without-ssl --prefix=/opt/node-0.4.3 && make && make install
ln -fs /opt/node-0.4.3  /opt/node
Oddities in thttpd
thttpd is what actually runs my websites and I discovered during some extended debugging sessions that it just does not like HTTP requests starting with a doubled "/" character. For example this works fine: 
wget http://www.acme.com/software/thttpd/
But this fails: 
wget http://www.acme.com//software/thttpd/
Previously it seems that Apache was (silently) fixing this up before it proxied requests. Now I have to do it myself, no big thing, but still a surprise.
All in all it was worth it to be able to run: 
dpkg --purge libapache2-mod-rpaf \
             apache2.2-common \
             apache2.2-bin \
             apache2-utils \
             apache2-mpm-prefork \
             apache2 \
             libaprutil1-dbd-sqlite3 \
             libaprutil1-ldap \
             libaprutil1 \
             libapr1
ObQuote: "Bad news. The fog's getting thicker." - Airplane!

24 February 2011

Dirk Eddelbuettel: Rcpp 0.9.2

The 0.9.2 release of Rcpp is now on CRAN and Debian. This version contains a build fix for the older 10.5.* version of OS X and its g++ 4.2.1 compiler; we now skip one test that upset it. CRAN builds for OS X should resume. We also added simple configuration support for the Intel Compiler; feedback would be welcome on the list. Lastly, documentation in the vignettes was expanded a little. The NEWS entry is below; more detail is in the ChangeLog file in the package and on the Rcpp Changelog page. 
0.9.2   2011-02-23
    o   The unitTest runit.Module.client.package.R is now skipped on older OS
        X releases as it triggers a bug with g++ 4.2.1 or older; OS X 10.6 is
        fine but as it no longer support ppc we try to accomodate 10.5 too
        Thanks to Simon Urbanek for pinning this down and Baptiste Auguie
        and Ken Williams for additonal testing 
    o   RcppCommon.h now recognises the Intel Compiler thanks to a short
        patch by Alexey Stukalov; this turns off Cxx0x and TR1 features too
    o   Three more setup questions were added to the Rcpp-FAQ vignette
    o   One question about RcppArmadillo was added to the Rcpp-FAQ vignette
Thanks to CRANberries, there is also a diff to the previous release 0.9.1. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

21 February 2011

Lucas Nussbaum: Debian Spring Cleanup

We have many orphaned packages in Debian. Those are packages that no longer have a maintainer willing to care for them. They are a problem for several reasons. Often, there have better alternatives (that s often why the maintainer gave up maintenance), but users keep installing them because they show up in apt-cache search. Or, they might be broken, without anybody noticing because they only have a few users. Also, developers need to take them into account. They might slow down transitions, have RC bugs that need fixing, etc. So, there are good reasons to remove some of the orphaned packages from the Debian archive. Not all of them. But those that have been orphaned for a long time without anybody stepping up to take over the maintenance, have very few users according to popcon, etc. Removing some of them also makes it easier to expose the ones that should really find an adopter. Also, that removal is not final. The good reason to do this now is that we are at the beginning of a release cycle, and that it will be easy to reintroduce packages that are really needed during the next two years. Also, packages (both source and binaries) are still available on snapshot.debian.org, so users can still install them from there, and re-uploading them to Debian is very easy if someone wants to adopt them. So, how do I proceed? I use bapase, and go through specific sets of packages (using a custom version of bapase to restrict the list to those packages). For example, orphaned packages that have a popcon lower than 50, have been orphaned for more than 500 days, and whose orphaning bugs have not been modified in the last 100 days. Then, I read the bug log, and decide if there s a reason to keep the package. If there s not, I request the removal. As of today, there are 471 orphaned packages in Debian. The goal is not to get down to zero, but it s certainly possible to get down to 200 or 250. How can you help? Start from the list, and find some easy targets. You can take a look at bug #483252 if you want to re-use my template. Also, one thing that is currently missing in the process is that orphaned packages that have reverse-dependencies should not be removed without removing their dependencies (if appropriate). An easy and efficient way to know if a given package has reverse (build-)?dependencies would be great, so I could integrate this info into bapase and exclude those packages from the list, or mark them somehow.

22 January 2011

Enrico Zini: A prototype webby markety appy thing

A prototype webby markety appy thing What better way to introduce my work at an Application Installer meeting than to come with a prototype package browser modeled after shopping sites developed in just a few hours? It's a little Flask webapp that just works on any Debian system, using the local apt-xapian-index as a backend. It has fast keyword search, faceted navigation and screenshots, and it runs on your system showing the packages that you have available. Screenshot of packageshelf To try it: 
git clone git://git.debian.org/users/enrico/pkgshelf.git
cd pkgshelf
./web-server.py
Then visit http://localhost:5000
It didn't have much interface polishing, as it's just a quick technology demo. However you can see that: Things that need doing: It's essentially JavaScript and CSS work. Anyone wants to play?

21 January 2011

Rapha&#235;l Hertzog: People behind Debian: Michael Vogt, synaptic and APT developer

Michael and his daughter Marie

Michael has been around for more than 10 years and has always contributed to the APT software family. He s the author of the first real graphical interface to APT synaptic. Since then he created software-center as part of his work for Ubuntu. Being the most experienced APT developer, he s naturally the coordinator of the APT team. Check out what he has to say about APT s possible evolutions. My questions are in bold, the rest is by Michael. Who are you? My name is Michael Vogt, I m married and have two little daughters. We live in Germany (near to Trier) and I work for Canonical as a software developer. I joined Debian as a developer in early 2000 and started to contribute to Ubuntu in 2004. What s your biggest achievement within Debian or Ubuntu? I can not decide on a single one so I will just be a bit verbose. From the very beginning I was interested in improving the package manager experience and the UI on top for our users. I m proud of the work I did with synaptic. It was one of the earliest UIs on top of apt. Because of my work on synaptic I got into apt development as well and fixed bugs there and added new features. I still do most of the uploads here, but nowadays David Kalnischkies is the most active developer. I also wrote a bunch of tools like gdebi, update-notifier, update-manager, unattended-upgrade and software-properties to make the update/install situation for the user easier to deal with. Most of the tools are written in python so I added a lot of improvements to python-apt along the way, including the initial high level apt interface and a bunch of missing low-level apt_pkg features. Julian Andres Klode made a big push in this area recently and thanks to his effort the bindings are fully complete now and have good documentation. My most recent project is software-center. Its aim is to provide a UI strongly targeted for end-users. The goal of this project is to make finding and installing software easy and beautiful. We have a fantastic collection of software to offer and software-center tries to present it well (including screenshots, instant search results and soon ratings&reviews). This builds on great foundations like aptdaemon by Sebastian Heinlein, screenshots.debian.net by Christoph Haas, ddtp.debian.org by Michael Bramer, apt-xapian-index by Enrico Zini and many others (this is what I love about free software, it usually adds , rarely takes away ). What are your plans for Debian Wheezy? For apt I would love to see a more plugable architecture for the acquire system. It would be nice to be able to make apt-get update (and the frontends that use this from libapt) be able to download additional data (like debtags or additional index file that contains more end-user targeted information). I also want to add some scripts so that apt (optionally) creates btrfs snapshots on upgrade and provide some easy way to rollback in case of problems. There is also some interesting work going on around making the apt problem resolver a more plugable part. This way we should be able to do much faster development. software-center will get ratings&reviews in the upstream branch, I really hope we can get that into Wheezy. If you could spend all your time on Debian, what would you work on? In that case I would start with a refactor of apt to make it more robust about ABI breaks. It would be possible to move much faster once this problem is solved (its not even hard, it just need to be done). Then I would add a more complete testsuite. Another important problem to tackle is to make maintainer scripts more declarative. I triaged a lot of upgrade bug reports (mostly in ubuntu though) and a lot of them are caused by maintainer script failures. Worse is that depending on the error its really hard for the user to solve the problem. There is also a lot of code duplication. Having a central place that contains well tested code to do these jobs would be more robust. Triggers help us a lot here already, but I think there is still more room for improvement. What s the biggest problem of Debian? That s a hard question :) I mostly like Debian the way it is. What frustrated me in the past were flamewars that could have been avoided. To me being respectful to each other is important, I don t like flames and insults because I like solving problems and fighting like this rarely helps that. The other attitude I don t like is to blame people and complain instead of trying to help and be positive (the difference between it sucks because it does not support $foo instead of it would be so helpful if we had $foo because it enables me to let me do $bar ). For a long time, I had the feeling you were mostly alone working on APT and were just ensuring that it keeps working. Did you also had this feeling and are things better nowadays ? I felt a bit alone sometimes :) That being said, there were great people like Eugene V. Lyubimkin and Otavio Salvador during my time who did do a lot of good work (especially at release crunch times) and helped me with the maintenance (but got interested in other area than apt later). And now we have the unstoppable David Kalnischkies and Julian Andres Klode. Apt is too big for a single person, so I m very happy that especially David is doing superb work on the day-to-day tasks and fixes (plus big project like multiarch and the important but not very thankful testsuite work). We talk about apt stuff almost daily, doing code reviews and discuss bugs. This makes the development process much more fun and healthy. Julian Andres Klode is doing interesting work around making the resolver more plugable and Christian Perrier is as tireless as always when it comes to the translations merging. I did a quick grep over the bzr log output (including all branch merges) and count around ~4300 total commits (including all revisions of branches merged). Of that there ~950 commits from me plus an additional ~500 merges. It was more than just ensuring that it keeps working but I can see where this feeling comes from as I was never very verbose. Apt also was never my only project, I am involved in other upstream work like synaptic or update-manager or python-apt etc). This naturally reduced the time available to hack on apt and spend time doing the important day-to-day bug triage, response to mailing list messages etc. One the python-apt side Julian Andres Klode did great work to improve the code and the documentation. It s a really nice interface and if you need to do anything related to packages and love python I encourage you to try it. Its as simple as: 
import apt
cache = apt.Cache()
cache["update-manager"].mark_install()
cache.commit()
Of course you can do much more with it (update-manager, software-center and lots of more tools use it). With pydoc apt you can get a good overview. The apt team always welcomes contributors. We have a mailing list and a irc channel and it s a great opportunity to solve real world problems. It does not matter if you want to help triage bugs or write documentation or write code, we welcome all contributors. You re also an Ubuntu developer employed by Canonical. Are you satisfied with the level of cooperation between both projects? What can we do to get Ubuntu to package new applications developed by Canonical directly in Debian? Again a tricky question :) When it comes to cooperation there is always room for improvement. I think (with my Canonical hat on) we do a lot better than we did in the past. And it s great to see the current DPL coming to Ubuntu events and talking about ways to improve the collaboration. One area that I feel that Debian would benefit is to be more positive about NMUs and shared source repositories (collab-maint and LowThresholdNmu are good steps here). The lower the cost is to push a patch/fix (e.g. via direct commit or upload) the more there will be. When it comes to getting packages into Debian I think the best solution is to have a person in Debian as a point of contact to help with that. Usually the amount of work is pretty small as the software will have a debian/* dir already with useful stuff in it. But it helps me a lot to have someone doing the Debian uploads, responding to the bugmail etc (even if the bugmail is just forwarded as upstream bugreports :) IMO it is a great opportunity especially for new packagers as they will not have to do a lot of packaging work to get those apps into Debian. This model works very well for me for e.g. gdebi (where Luca Falavigna is really helpful on the Debian side). Is there someone in Debian that you admire for his contributions? There are many people I admire. Probably too many to mention them all. I always find it hard to single out individual people because the project as a whole can be so proud of their achievements. The first name that comes to my mind is Jason Gunthorpe (the original apt author) who I ve never met. The next is Daniel Burrows who I met and was inspired by. David Kalnischkies is doing great work on apt. From contributing his first (small) patch to being able to virtually fix any problem and adding big features like multiarch support in about a year. Sebastian Heinlein for aptdaemon. Christian Perrier has always be one of my heroes because he cares so much about i18n. Christoph Haas for screenshots.debian.net, Michael Bramer for his work on debian translated package descriptions.
Thank you to Michael 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.

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

16 January 2011

Gregor Herrmann: RC bugs 2011/01 - 2011/02

new year, new RC bugs most of the fixes below are for newly reported bugs in versions that don't affect squeeze. the rest are mainly uploads of packages or patches prepared by others.

13 January 2011

Cyril Brulebois: X11R7.6: Katamari summary

X11R7.6 got released on the 20th of December 2010. There were several status updates about XServer 1.9 in experimental on this blog previously, but here s a more thorough review of this katamari. Terminology: that s how upstream calls a badged annual rollup release. In other words, the server, drivers, client libraries, protocols, fonts, and basic applications are all individually released, and a rollup of all those is released from time to time, with a version for all of those components. The term comes from a series of video games. (Explanations taken from a message by Alan Coopersmith.) Katamaris are released with a consolidated changelog, where all components and versions are listed. There s also a git shortlog available for each component, pointing back to freedesktop s git web interface for each and every commit. I modified the table of versions to get the following table, dropping the X11R7.5 column, and adding a distribution one, so as to mention where each component for X11R7.6 can be found. It boils down mostly to: So there s the summary:
Type Component Version Distribution
xserver 1.9.3 experimental
app bdftopcf 1.0.3 unstable
app iceauth 1.0.4 experimental
app luit 1.1.0 experimental
app mkfontdir 1.0.6 unstable
app mkfontscale 1.0.8 unstable
app sessreg 1.0.6 unstable
app setxkbmap 1.2.0 experimental
app smproxy 1.0.4 experimental
app x11perf 1.5.2 experimental
app xauth 1.0.5 unstable
app xbacklight 1.1.2 will be dropped
app xcmsdb 1.0.3 experimental
app xcursorgen 1.0.4 experimental
app xdpyinfo 1.2.0 experimental
app xdriinfo 1.0.4 experimental
app xev 1.1.0 experimental
app xgamma 1.0.4 experimental
app xhost 1.0.4 experimental
app xinput 1.5.3 unstable
app xkbcomp 1.2.0 experimental
app xkbevd 1.1.2 experimental
app xkbutils 1.0.3 experimental
app xkill 1.0.3 experimental
app xlsatoms 1.1.0 unstable
app xlsclients 1.1.1 experimental
app xmodmap 1.0.5 experimental
app xpr 1.0.3 will be dropped
app xprop 1.2.0 experimental
app xrandr 1.3.4 experimental
app xrdb 1.0.7 experimental
app xrefresh 1.0.4 experimental
app xset 1.2.1 experimental
app xsetroot 1.1.0 experimental
app xvinfo 1.1.1 experimental
app xwd 1.0.4 experimental
app xwininfo 1.1.1 experimental
app xwud 1.0.3 experimental
data bitmaps 1.1.1 unstable
data cursors 1.0.3 unstable
doc xorg-docs 1.6 unstable
doc xorg-sgml-doctools 1.6 unstable
driver xf86-input-acecad 1.4.0 experimental
driver xf86-input-aiptek 1.3.1 experimental
driver xf86-input-evdev 2.5.0 experimental
driver xf86-input-joystick 1.5.0 experimental
driver xf86-input-keyboard 1.5.0 experimental
driver xf86-input-mouse 1.6.0 experimental
driver xf86-input-synaptics 1.3.0 experimental
driver xf86-input-vmmouse 12.6.10 experimental
driver xf86-input-void 1.3.1 experimental
driver xf86-video-apm 1.2.3 experimental
driver xf86-video-ark 0.7.3 experimental
driver xf86-video-ast 0.91.10 dropped
driver xf86-video-ati 6.13.2 experimental
driver xf86-video-chips 1.2.3 experimental
driver xf86-video-cirrus 1.3.2 experimental
driver xf86-video-dummy 0.3.4 experimental
driver xf86-video-fbdev 0.4.2 experimental
driver xf86-video-geode 2.11.10 todo: needs upload
driver xf86-video-glide 1.1.0 experimental
driver xf86-video-glint 1.2.5 experimental
driver xf86-video-i128 1.3.4 experimental
driver xf86-video-i740 1.3.2 experimental
driver xf86-video-intel 2.13.0 experimental
driver xf86-video-mach64 6.8.2 experimental
driver xf86-video-mga 1.4.13 experimental
driver xf86-video-neomagic 1.2.5 experimental
driver xf86-video-newport 0.2.3 todo: needs upload
driver xf86-video-nv 2.1.18 will be dropped
driver xf86-video-r128 6.8.1 experimental
driver xf86-video-rendition 4.2.4 experimental
driver xf86-video-s3 0.6.3 experimental
driver xf86-video-s3virge 1.10.4 experimental
driver xf86-video-savage 2.3.1 experimental
driver xf86-video-siliconmotion 1.7.4 experimental
driver xf86-video-sis 0.10.3 experimental
driver xf86-video-sisusb 0.9.4 experimental
driver xf86-video-suncg14 1.1.1 experimental
driver xf86-video-suncg3 1.1.1 experimental
driver xf86-video-suncg6 1.1.1 experimental
driver xf86-video-sunffb 1.2.1 experimental
driver xf86-video-sunleo 1.2.0 experimental
driver xf86-video-suntcx 1.1.1 experimental
driver xf86-video-tdfx 1.4.3 experimental
driver xf86-video-tga 1.2.1 experimental
driver xf86-video-trident 1.3.4 experimental
driver xf86-video-tseng 1.2.4 experimental
driver xf86-video-v4l 0.2.0 dropped
driver xf86-video-vesa 2.3.0 experimental
driver xf86-video-vmware 11.0.3 experimental
driver xf86-video-voodoo 1.2.4 experimental
driver xf86-video-wsfb 0.3.0 dropped
driver xf86-video-xgi 1.6.0 dropped
driver xf86-video-xgixp 1.8.0 dropped
font fonts skipped
lib libAppleWM 1.4.0 not for us
lib libFS 1.0.3 unstable
lib libICE 1.0.7 unstable
lib libSM 1.2.0 unstable
lib libWindowsWM 1.0.1 not for us
lib libX11 1.4.0 experimental
lib libXScrnSaver 1.2.1 unstable
lib libXau 1.0.6 unstable
lib libXaw 1.0.8 unstable
lib libXcomposite 0.4.3 unstable
lib libXcursor 1.1.11 unstable
lib libXdamage 1.1.3 unstable
lib libXdmcp 1.1.0 unstable
lib libXext 1.2.0 experimental
lib libXfixes 4.0.5 unstable
lib libXfont 1.4.3 experimental
lib libXft 2.2.0 experimental
lib libXi 1.4.0 experimental
lib libXinerama 1.1.1 unstable
lib libXmu 1.1.0 unstable
lib libXpm 3.5.9 unstable
lib libXrandr 1.3.1 unstable
lib libXrender 0.9.6 unstable
lib libXRes 1.0.5 unstable
lib libXt 1.0.9 experimental
lib libXtst 1.2.0 unstable
lib libXv 1.0.6 unstable
lib libXvMC 1.0.6 unstable
lib libXxf86dga 1.1.2 unstable
lib libXxf86vm 1.1.1 unstable
lib libdmx 1.1.1 unstable
lib libfontenc 1.1.0 unstable
lib libpciaccess 0.12.0 unstable
lib libxkbfile 1.0.7 unstable
lib libxtrans 1.2.6 unstable
proto applewmproto 1.4.1 not for us
proto bigreqsproto 1.1.1 unstable
proto compositeproto 0.4.2 unstable
proto damageproto 1.2.1 unstable
proto dmxproto 2.3 unstable
proto dri2proto 2.3 unstable
proto fixesproto 4.1.2 unstable
proto fontsproto 2.1.1 unstable
proto glproto 1.4.12 unstable
proto inputproto 2.0.1 unstable
proto kbproto 1.0.5 unstable
proto randrproto 1.3.2 unstable
proto recordproto 1.14.1 unstable
proto renderproto 0.11.1 unstable
proto resourceproto 1.1.1 unstable
proto scrnsaverproto 1.2.1 unstable
proto videoproto 2.3.1 unstable
proto windowswmproto 1.0.4 not for us
proto xcmiscproto 1.2.1 unstable
proto xextproto 7.1.2 unstable
proto xf86bigfontproto 1.2.0 unstable
proto xf86dgaproto 2.1 unstable
proto xf86driproto 2.1.0 unstable
proto xf86vidmodeproto 2.3 unstable
proto xineramaproto 1.2 unstable
proto x11proto 7.0.20 unstable
util makedepend 1.0.3 unstable
util macros 1.11.0 unstable
xcb pthread-stubs 0.3 unstable
xcb libxcb 1.7 experimental
xcb proto 1.6 unstable

6 January 2011

Gunnar Wolf: Back with Ruby on Debian polemics

Once again, a polemic regarding how to properly integrate the Ruby language and libraries with the Debian distribution has been ignited. Similar arguments were presented in November and December 2008 and September 2010 And excuse me for just refering to my own blog, but there are links to some other posts from there... and there will surely be many others I just missed. There were even nice collaboration attempts (such as DebGem, announced in January 2009... But which apparently never stuck on, as it is still listed as in its public Beta period and lists only support for Debian 4.0 and Ubuntu 8.04 and 8.10). Some days ago, while I was on vacation, I received a mail from Lucas Nussbaum expressing the burnout he had been suffering from this situation. Some days after that, he posted a corresponding blog post - Giving up on Ruby packaging. The comments following his post are most interesting The one comment I'd like to highlight (noting I skimmed a whole deal of them) is by Paul Brannan, one of the original RubyGems authors. Yes, possibly the design criteria for Gems included some mutually-conflicting goals, and they cover some of Debian's goals. Unfortunately, this conflicting criteria... Was resolved to the opposite way we would have wanted (specifically, that a sysadmin should be able to install software with the same tools he was already familiar with). And of course, there are deeper disagreements, which are rightly stemmed from different priorities: Debian (+derivatives) is meant to make user's and sysadmin's lifes simpler. Gems are meant to make developers' lifes simpler. And while all developers are some sort of users, and sysadminsthe reverse is (obviously) not so. A developer maintaining several different codebases will surely suffer (well, this particular developer has surely suffered) if he has to maintain them all using coherent versions of system libraries. When a system is programmed, its developers want to use the greatest, latest tools to offer the best experience and functionality. And it's natural for libraries to evolve over time. However, any sysadmin will grind their teeth at the prospect of having many different versions of libraries, as the Gem model proposes. Why? Well, I was bitten by a minor example of it Bug fixes do not get backported. Of course, if simple bugs are not backported, security and stability of the system as a whole suffers. Often, new software versions will not only add functionality, but improve on how things are done. Not only bugs get corrected, but we get better response times, better memory handling, etc. It might sound harsh to say this, and even more, as a developer it feels I am talking against myself But while development time should be minimized during the system design/implementation, once systems are in production, it should be used to allow for friendlier sysadmin relations. I have to wear both hats at my real-life job. So, what is my take on this? Of course, blaming myself for choosing the wrong version is a no-go. When evaluating a library before using it in my projects, I try to look at its history and API-stability. APIs that change often speak about immature libraries which are still trying to get the right way to implement their functionality; just-started projects might be great and revolutionary, but they do not yet show any kind of long-term committment... And can lead (and have often led me) to painful rewrites when the Next Big Thing is reached. As for the users: Even if your favorite language has the best and friendliest distribution method, users just do not care about what language was a particular piece of software implemented in. Users want to be able to install and uninstall with their system's usual tools. Directly using Gems, CPAN, PEAR and whatnot is just unnatural for users, however convenient they are for developers. Distributions offer a non-technical advantage in this regard as well: A human filter. As an example, as I write this there are 19392 Ruby Gems and 19092 Perl modules in CPAN (note that CPAN stores some older versions but discourages authors from keeping too many - So no, they are still very different in size). Debian has around 30,000 packages. Why is that? Because all Debian packages _must_ be human-generated, human-reviewed, human-submitted. This means, a person must think each packaged piece of code is worth packaging, is stable enough and provides value to users as it is, and is fit for being part of a stable release. I am not saying with this that 90% of CPAN and Gems are crap I am saying that they are probably early implementations, to be installed, tested and improved by developers, and still not apt for general public use. Or maybe not interesting enough to be packaged as a service for the non-techie public at large. Oh, and one last point: Ruby is not a new language anymore. It is a mature, powerful language with different implementations, every time more stable... But it is a language deeply affected by the (not so new anymore either) the appearance of Rails. Why do I say this? Because although the language is in no way tied to Web development, many of its strongest uses are Web-oriented. How does this affect the current discussion? Well, because many people argue that users are no longer needed to install the software. Web systems are installed by sysadmins and used via a Web browser, and sysadmins are expected be more skilled than casual users. Still, in Debian (and in other distributions, surely) we try to make sysadmin's lives simpler I have (again, talking out of personal experience) installed several webapps (and system tools, and whatnot) for which I never followed any instructions besides aptitude install foo Using different languages, frameworks, and so on. Can I troubleshoot their installs? Probably, as there is a common logic for how the distribution I have chosen and specialized in works. Can I find causes for bugs in them? Possibly, although there are some languages and frameworks I dare not touch. Can I get help on getting them out of a tight spot? Surely, as there is a central bug tracking system for my distribution And one of the maintainer's tasks is to separate the problems related to the distribution (packaging, installing, simple user questions and misconceptions) to those derived from real bugs upstream. Anyway I am not saying that our way is the best way. No, by a long shot. Again, developers should have an easy, convenient way for installing whatever they want to play with. And to publish it without jumping through hoops. With this post, I'm only trying to express again why Debian works the way it does. And hope for better cooperation in the future. And as for several comments of what I read in Lucas' post, I think that there is interest for this synergy among some of the most committed Ruby people.

7 December 2010

Theodore Ts'o: Working on Technology at Startups

Richard Tibbetts has called me out for conflating Web 2.0 startups with all startups in my recent blog posting, Google has a problem retaining great engineers? Bullcrap . His complaint was that I was over generalizing from Web 2.0 startups to all startups. He s right, of course. The traditional technology startup by definition does have a large amount technology work that needs to be done, in addition to the business development work. However, things have changed a lot even for technology startups. Consider a company like Sequent Computer Systems, which started in 1983. At the time the founders had a key idea, which was to use multiple commodity intel CPU s to create first SMP, and then later, NUMA minicomputers. But in order to do that, they had to design, build and manufacture a huge mount of hardware, as well as develop a whole new Unix-derived operating system, just to bring that core idea to market. These days, the founder or founders will have a core idea, which they will hopefully patent, to prevent competitors from replicating their work, just as before. However, these days there is a huge selection of open source software so there is much less technology that needs to be re-developed / re-invented in order to bring that idea to market. From Linux and BSD at the operating system level, to databases like MySQL, Apache web servers, etc., there is an awful lot for the startup to chose from. This is all goodness, of course. But it means that most of the technology developed in a typical startup will tend to be focused on supporting the core idea that was developed by the founder. If a company is focused on databases, they probably won t be interested in supporting me to do my file system work. Why should they? There s lots of open source file systems they can use; one of them will probably meet their needs. So while it s obvious that you can do technology at large variety of companies, of different sizes, I don t think it s arrogance to say that there are certain types of technology that can only be done at Google, or maybe at a very small subset of other companies. I m pretty confident, for example, that Google has the world s largest number of computers in its various data centers around the world. That means there are certain things that don t make sense at other companies, but which absolutely makes sense at our scale. In addition, Google s business model means allows us to pursue open source projects such as Chrome and Android that wouldn t make sense at other companies. With Android in particular, it means that multiple firmware updates for any given handset model, if it causes people to use the web more and drive more advertising revenue, makes sense and so it s something we can pursue in comparison to Nokia, which gets its revenue from hardware sales, so a firmware update that extends the life of a handset is actually a bad thing for them; better to force you to upgrade an handset every year or two. So I think Richard misunderstood me if he thought I was trying to make the argument that Google is the only place where you can do interesting technical work. That s obviously not true, of course. But I do think there are many examples of technical work which don t make business sense to do at smaller companies, and startups in particular have to be very much focused on bringing the founder s idea to market, and all else has to be subordinated to that goal. And one of the most interesting developments is how the combination of commoditized and standardized hardware, and comoditized software in the form of open source, has changed the game for startups. For most startups, though, open source software is something that they will use, but not necessarily develop except in fairly small ways. Many of the economic arguments in favor of releasing code as open source, and dedicating a significant fraction of an engineer s time to serve as a OSS project maintainer or kernel subsystem maintainer, are ones that make much more sense at a very large company like Google or IBM. That s not because startups are evil, or deficient in any way; just the economic realities that at a successful startup, everything has to be subordinated to the central goal of proving that they have a sustainable, scalable business model and that they have a good product/market fit. Everything else, and that includes participating in an open source community, is very likely a distraction from that central goal. No related posts.

5 December 2010

Christoph Egger: The erlang experience

This week I had to write a little tool that would collect input on different channels, via socket / netcat, via a http server, .... Calls for a parralel Design -- Maybe a good place to write something real in Erlang. While erlang itself was really nice to write -- I do like Prolog as well as the bunch of functional languages -- doing networking in erlang seems a bit special, the interfaces just aren't thin wrappers around the libc stuff. Getting a Socket Text interface What sounds like a easy challenge to accomplish was actually harder than expected. All I found was some way to pass binaries representing erlang code over a socket and evaluating it remotle. While it's nice that such things are as easy to do as they are it doesn't help me with my task of moving simple strings. 
start() ->
     ok, Listen  = gen_tcp:listen(51622, [binary,  packet, 0 ,
                                          reuseaddr, true ,
                                          active, true ]),
    spawn(fun () -> accept_loop(Listen) end).
accept_loop(Listen) ->
     ok, Socket  = gen_tcp:accept(Listen),
    accept_loop(Listen),
    handle(Socket)
handle(Socket) ->
    receive
         tcp, Socket, Bin  ->
            io:format("~p~n", binary_to_list(Bin));
         tcp_closed, Socket  ->
            Buffer
    end.
So the socket is now up and receives text as wanted. However, as we are already runnign a parralel program it would be nice to be hable to handle multiple socket connections in parralel right? For that we just need to add a spawn() at the right place. The right place is not the handle(Socket) but the accept_loop(Listen) because the process that called accept will receive all the tcp messages. This last part was quite obvious after finding the documentation of the active, _ properties for the socket. always here means that you'll receive all data from the socket as erlang Messages, once delivers one package and waits until it is activated again and false requires calling a method -- this would have been possible as well when forking handle(Socket). The web server Ok we also want a webserver. We do not want to run some webapplication inside appache or so, just do some post/get and simple pages. Erlang here provides a built-in httpd with some mod_esi that calls some function depending on the URL used. It doesn't do anything fancy like templating or DB backends or stuff, just taking strings and building the http answers. Unfortunately there are no examples around and basically noone seems to be using this combination (apart from some hacks like mine probably). So as I needed to get some additional information into the handler function (a Pid to connect to some service), I, as a novice, just couldn't find a way. Asking on IRC the solution was rather simple: Just using erlang's process registry. For more complex stuf gproc might prove usefull here. Result I guess I've got a huge step farther in programming erlang now. The manpages are easily found by your search engine -- for python I have to either walk through the (well structured) online documentation or search for the right link in the search results, for erlang they're typically first. Also Joe Armstrong's Books as proven usefull. The most dificult part probably is getting around all the nice extras you can do (transfering functions over sockets et al) and find out how to do the thing you need.

1 December 2010

Pietro Abate: bypassing the apt-get solver

Here at mancoosi we have been working for quite a while to promote and advance solver technology for FOSS distributions. We are almost at the end of the project and it is important to make the mancoosi technology relevant for the community. On goal of the project is to provide a prototype that uses part of the results of mancoosi that can based to install/remove/upgrade packages on a user machine. We certainly don't want to create yet another meta installer. This would be very time consuming and certainly going beyond the scope of the project. The idea is to create a prototype, that can work as an apt-get drop in replacement that will allow everybody to play with different solvers and installation criteria. A very first integration step is a small shell script apt-mancoosi that tries to put together different tools that we have implemented during the project. Roberto wrote extensively about his experience with apt-mancoosi a while ago showing that somehow the mancoosi tools are already usable, as proof of concept, to experiment with all solvers participating to the Misc competition. On notable obstacle we encountered with apt-mancoosi is how to pipe the result of an external solver to apt-get to effectively install the packages proposed as solution. Apt-mancoosi fails to be a drop-in replacement for apt-get exactly for this reason. The "problem" is quite simple : The idea at the beginning was to pass to apt-get, on the command line, a request that effectively represents a complete solution. We expected that, since this was already a locked-down solution, apt-get would have just installed all packages without any further modification to the proposed installation set. Of course, since apt-get is designed to satisfy a user request, and not just to install packages, we quickly realized that our evil plan was doomed to failure. The only option left, was to use libapt directly, but the idea of programming in c++ quickly made me to desist. After a bit of research (not that much after all), I finally found a viable solution to our problems in ''python-apt'' that is a low level and wrapper around libapt. This definitely made my day. Now the juicy details. the problem was to convince apt to completely bypass the solver part and just call the installer. First a small intro. python-apt has an extensive documentation with a couple of tutorials. Using python-apt is actually pretty easy (some snippet from the python-apt doco) :
import apt

# First of all, open the cache
cache = apt.Cache()
# Now, lets update the package list
cache.update()
here we open the cache (apt.Cache is a wrapper around the low level binding in the apt_pkg module), then we update the package list. This is equivalent to apt-get update . Installing a package is equally easy :
import apt
cache = apt.Cache()
pkg = cache['python-apt']

# Mark python-apt for install
pkg.mark_install()

# Now, really install it
cache.commit()
Now, the method mark_install of the module package will effectively run the solver to resolve and mark all the dependencies of the package python-apt. This is the default behavior when apt-get is used on the command line. This method has however three optional arguments that are just what I was looking for, that is autoFix, autoInst and fromUser . The explanation from the python-apt doco is quite clear.
mark_install(*args, **kwds)
Mark a package for install.
If autoFix is True, the resolver will be run, trying to fix broken packages. This is the default.
If autoInst is True, the dependencies of the packages will be installed automatically. This is the default.
If fromUser is True, this package will not be marked as automatically installed. This is the default. Set it to False if you want to be able to automatically remove the package at a later stage when no other package depends on it.
What we want is to set autoFix and autoInst to false to completely bypass the solver. So imagine that an external solver can give use a string of the form : bash+ dash=1.4 baobab- that basically asks to install bash to the newest version, dash at version 1.4 and remove baobab. Suppose also that this is a complete solution, that is, all dependencies are satisfied and there are no conflicts. The work flow of mpm (mancoosi package manager) is as follows : We already have a first prototype on the mancoosi svn. It's not released yet as we are waiting to do more testing, add more options and make it stable enough for testing. Maybe one day, this will be uploaded to debian. This is the trace of a successful installation of a package in a lenny chroot. The solver used here is the p2 solver
dev:~/mpm# ./mpm.py -c apt.conf install baobab
Running p2cudf-paranoid-1.6 solver ...
Validate solution ...
loading CUDF ...
loading solution ...
Summary of proposed changes:
new: 30
removed: 0
replaced: 0
upgraded: 0
downgraded: 0
unsatisfied recommends:: 8
changed: 30
uptodate: 322
notuptodate: 116

New packages: baobab (2.30.0-2) dbus-x11 (1.2.24-3) gconf2 (2.28.1-5)
gconf2-common (2.28.1-5) gnome-utils-common (2.30.0-2)
libatk1.0-0 (1.30.0-1) libcairo2 (1.8.10-6) libdatrie1 (0.2.4-1)
libdbus-glib-1-2 (0.88-2) libgconf2-4 (2.28.1-5) libgtk2.0-0 (2.20.1-2)
libgtk2.0-common (2.20.1-2) libgtop2-7 (2.28.1-1) libgtop2-common (2.28.1-1)
libidl0 (0.8.14-0.1) libjasper1 (1.900.1-7+b1) liborbit2 (1:2.14.18-0.1)
libpango1.0-0 (1.28.3-1) libpango1.0-common (1.28.3-1)
libpixman-1-0 (0.16.4-1) libthai-data (0.1.14-2) libthai0 (0.1.14-2)
libtiff4 (3.9.4-5) libxcb-render-util0 (0.3.6-1) libxcb-render0 (1.6-1)
libxcomposite1 (1:0.4.2-1) libxcursor1 (1:1.1.10-2) libxrandr2 (2:1.3.0-3)
psmisc (22.11-1) shared-mime-info (0.71-3)
Removed packages:
Replaced packages:
Upgraded packages:

Selecting previously deselected package libatk1.0-0.
(Reading database ... 28065 files and directories currently installed.)
Unpacking libatk1.0-0 (from .../libatk1.0-0_1.30.0-1_i386.deb) ...
Selecting previously deselected package libpixman-1-0.
Unpacking libpixman-1-0 (from .../libpixman-1-0_0.16.4-1_i386.deb) ...
Selecting previously deselected package libxcb-render0.
Unpacking libxcb-render0 (from .../libxcb-render0_1.6-1_i386.deb) ...
Selecting previously deselected package libxcb-render-util0.
Unpacking libxcb-render-util0 (from .../libxcb-render-util0_0.3.6-1_i386.deb) ...
Selecting previously deselected package libcairo2.
Unpacking libcairo2 (from .../libcairo2_1.8.10-6_i386.deb) ...
Selecting previously deselected package libdbus-glib-1-2.
Unpacking libdbus-glib-1-2 (from .../libdbus-glib-1-2_0.88-2_i386.deb) ...
Selecting previously deselected package libidl0.
Unpacking libidl0 (from .../libidl0_0.8.14-0.1_i386.deb) ...
Selecting previously deselected package liborbit2.
Unpacking liborbit2 (from .../liborbit2_1%3a2.14.18-0.1_i386.deb) ...
Selecting previously deselected package gconf2-common.
Unpacking gconf2-common (from .../gconf2-common_2.28.1-5_all.deb) ...
Selecting previously deselected package libgconf2-4.
Unpacking libgconf2-4 (from .../libgconf2-4_2.28.1-5_i386.deb) ...
Selecting previously deselected package libgtk2.0-common.
Unpacking libgtk2.0-common (from .../libgtk2.0-common_2.20.1-2_all.deb) ...
Selecting previously deselected package libjasper1.
Unpacking libjasper1 (from .../libjasper1_1.900.1-7+b1_i386.deb) ...
Selecting previously deselected package libpango1.0-common.
Unpacking libpango1.0-common (from .../libpango1.0-common_1.28.3-1_all.deb) ...
Selecting previously deselected package libdatrie1.
Unpacking libdatrie1 (from .../libdatrie1_0.2.4-1_i386.deb) ...
Selecting previously deselected package libthai-data.
Unpacking libthai-data (from .../libthai-data_0.1.14-2_all.deb) ...
Selecting previously deselected package libthai0.
Unpacking libthai0 (from .../libthai0_0.1.14-2_i386.deb) ...
Selecting previously deselected package libpango1.0-0.
Unpacking libpango1.0-0 (from .../libpango1.0-0_1.28.3-1_i386.deb) ...
Selecting previously deselected package libtiff4.
Unpacking libtiff4 (from .../libtiff4_3.9.4-5_i386.deb) ...
Selecting previously deselected package libxcomposite1.
Unpacking libxcomposite1 (from .../libxcomposite1_1%3a0.4.2-1_i386.deb) ...
Selecting previously deselected package libxcursor1.
Selecting previously deselected package libxrandr2.
Unpacking libxrandr2 (from .../libxrandr2_2%3a1.3.0-3_i386.deb) ...
Selecting previously deselected package shared-mime-info.
Unpacking shared-mime-info (from .../shared-mime-info_0.71-3_i386.deb) ...
Selecting previously deselected package libgtk2.0-0.
Unpacking libgtk2.0-0 (from .../libgtk2.0-0_2.20.1-2_i386.deb) ...
Selecting previously deselected package libgtop2-common.
Unpacking libgtop2-common (from .../libgtop2-common_2.28.1-1_all.deb) ...
Selecting previously deselected package libgtop2-7.
Unpacking libgtop2-7 (from .../libgtop2-7_2.28.1-1_i386.deb) ...
Selecting previously deselected package psmisc.
Unpacking psmisc (from .../psmisc_22.11-1_i386.deb) ...
Selecting previously deselected package dbus-x11.
Unpacking dbus-x11 (from .../dbus-x11_1.2.24-3_i386.deb) ...
Selecting previously deselected package gconf2.
Unpacking gconf2 (from .../gconf2_2.28.1-5_i386.deb) ...
Selecting previously deselected package gnome-utils-common.
Unpacking gnome-utils-common (from .../gnome-utils-common_2.30.0-2_all.deb) ...
Selecting previously deselected package baobab.
Unpacking baobab (from .../baobab_2.30.0-2_i386.deb) ...
Processing triggers for man-db ...
Setting up libatk1.0-0 (1.30.0-1) ...
Setting up libpixman-1-0 (0.16.4-1) ...
Setting up libxcb-render0 (1.6-1) ...
Setting up libxcb-render-util0 (0.3.6-1) ...
Setting up libcairo2 (1.8.10-6) ...
Setting up libdbus-glib-1-2 (0.88-2) ...
Setting up libidl0 (0.8.14-0.1) ...
Setting up liborbit2 (1:2.14.18-0.1) ...
Setting up gconf2-common (2.28.1-5) ...

Creating config file /etc/gconf/2/path with new version
Setting up libgconf2-4 (2.28.1-5) ...
Setting up libgtk2.0-common (2.20.1-2) ...
Setting up libjasper1 (1.900.1-7+b1) ...
Setting up libpango1.0-common (1.28.3-1) ...
Cleaning up font configuration of pango...
Updating font configuration of pango...
Cleaning up category xfont..
Updating category xfont..
Setting up libdatrie1 (0.2.4-1) ...
Setting up libthai-data (0.1.14-2) ...
Setting up libthai0 (0.1.14-2) ...
Setting up libpango1.0-0 (1.28.3-1) ...
Setting up libtiff4 (3.9.4-5) ...
Setting up libxcomposite1 (1:0.4.2-1) ...
Setting up libxcursor1 (1:1.1.10-2) ...
Setting up libxrandr2 (2:1.3.0-3) ...
Setting up shared-mime-info (0.71-3) ...
Setting up libgtk2.0-0 (2.20.1-2) ...
Setting up libgtop2-common (2.28.1-1) ...
Setting up libgtop2-7 (2.28.1-1) ...
Setting up psmisc (22.11-1) ...
Setting up dbus-x11 (1.2.24-3) ...
Setting up gconf2 (2.28.1-5) ...
update-alternatives: using /usr/bin/gconftool-2 to provide /usr/bin/gconftool (gconftool) in auto mode.
Setting up gnome-utils-common (2.30.0-2) ...
Setting up baobab (2.30.0-2) ...
Broken: 0
InstCount: 30
DelCount: 0
dev:~/mpm#
I think we'll keep working on this python prototype for a while, but this is not certainly what we want to propose to the community. The mancoosi package manager is probably going to be written in Ocaml and integrated with dose3 and libcudf. This will allow us to gain speed and have a solid language to develop with (nothing against python, but we don't feel that a scripting language is suitable for an essential component as a package manager). Time will tell. For the moment this is just vapor-ware ...

22 November 2010

Petter Reinholdtsen: Lenny->Squeeze upgrades of the Gnome and KDE desktop, now with apt-get autoremove

Michael Biebl suggested to me on IRC, that I changed my automated upgrade testing of the Lenny Gnome and KDE Desktop to do apt-get autoremove when using apt-get. This seem like a very good idea, so I adjusted by test scripts and can now present the updated result from today: This is for Gnome: Installed using apt-get, missing with aptitude
apache2.2-bin aptdaemon baobab binfmt-support browser-plugin-gnash cheese-common cli-common cups-pk-helper dmz-cursor-theme empathy empathy-common freedesktop-sound-theme freeglut3 gconf-defaults-service gdm-themes gedit-plugins geoclue geoclue-hostip geoclue-localnet geoclue-manual geoclue-yahoo gnash gnash-common gnome gnome-backgrounds gnome-cards-data gnome-codec-install gnome-core gnome-desktop-environment gnome-disk-utility gnome-screenshot gnome-search-tool gnome-session-canberra gnome-system-log gnome-themes-extras gnome-themes-more gnome-user-share gstreamer0.10-fluendo-mp3 gstreamer0.10-tools gtk2-engines gtk2-engines-pixbuf gtk2-engines-smooth hamster-applet libapache2-mod-dnssd libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libart2.0-cil libboost-date-time1.42.0 libboost-python1.42.0 libboost-thread1.42.0 libchamplain-0.4-0 libchamplain-gtk-0.4-0 libcheese-gtk18 libclutter-gtk-0.10-0 libcryptui0 libdiscid0 libelf1 libepc-1.0-2 libepc-common libepc-ui-1.0-2 libfreerdp-plugins-standard libfreerdp0 libgconf2.0-cil libgdata-common libgdata7 libgdu-gtk0 libgee2 libgeoclue0 libgexiv2-0 libgif4 libglade2.0-cil libglib2.0-cil libgmime2.4-cil libgnome-vfs2.0-cil libgnome2.24-cil libgnomepanel2.24-cil libgpod-common libgpod4 libgtk2.0-cil libgtkglext1 libgtksourceview2.0-common libmono-addins-gui0.2-cil libmono-addins0.2-cil libmono-cairo2.0-cil libmono-corlib2.0-cil libmono-i18n-west2.0-cil libmono-posix2.0-cil libmono-security2.0-cil libmono-sharpzip2.84-cil libmono-system2.0-cil libmtp8 libmusicbrainz3-6 libndesk-dbus-glib1.0-cil libndesk-dbus1.0-cil libopal3.6.8 libpolkit-gtk-1-0 libpt2.6.7 libpython2.6 librpm1 librpmio1 libsdl1.2debian libsrtp0 libssh-4 libtelepathy-farsight0 libtelepathy-glib0 libtidy-0.99-0 media-player-info mesa-utils mono-2.0-gac mono-gac mono-runtime nautilus-sendto nautilus-sendto-empathy p7zip-full pkg-config python-aptdaemon python-aptdaemon-gtk python-axiom python-beautifulsoup python-bugbuddy python-clientform python-coherence python-configobj python-crypto python-cupshelpers python-elementtree python-epsilon python-evolution python-feedparser python-gdata python-gdbm python-gst0.10 python-gtkglext1 python-gtksourceview2 python-httplib2 python-louie python-mako python-markupsafe python-mechanize python-nevow python-notify python-opengl python-openssl python-pam python-pkg-resources python-pyasn1 python-pysqlite2 python-rdflib python-serial python-tagpy python-twisted-bin python-twisted-conch python-twisted-core python-twisted-web python-utidylib python-webkit python-xdg python-zope.interface remmina remmina-plugin-data remmina-plugin-rdp remmina-plugin-vnc rhythmbox-plugin-cdrecorder rhythmbox-plugins rpm-common rpm2cpio seahorse-plugins shotwell software-center system-config-printer-udev telepathy-gabble telepathy-mission-control-5 telepathy-salut tomboy totem totem-coherence totem-mozilla totem-plugins transmission-common xdg-user-dirs xdg-user-dirs-gtk xserver-xephyr
Installed using apt-get, removed with aptitude
cheese ekiga eog epiphany-extensions evolution-exchange fast-user-switch-applet file-roller gcalctool gconf-editor gdm gedit gedit-common gnome-games gnome-games-data gnome-nettool gnome-system-tools gnome-themes gnuchess gucharmap guile-1.8-libs libavahi-ui0 libdmx1 libgalago3 libgtk-vnc-1.0-0 libgtksourceview2.0-0 liblircclient0 libsdl1.2debian-alsa libspeexdsp1 libsvga1 rhythmbox seahorse sound-juicer system-config-printer totem-common transmission-gtk vinagre vino
Installed using aptitude, missing with apt-get
gstreamer0.10-gnomevfs
Installed using aptitude, removed with apt-get
[nothing]
This is for KDE: Installed using apt-get, missing with aptitude
ksmserver
Installed using apt-get, removed with aptitude
kwin network-manager-kde
Installed using aptitude, missing with apt-get
arts dolphin freespacenotifier google-gadgets-gst google-gadgets-xul kappfinder kcalc kcharselect kde-core kde-plasma-desktop kde-standard kde-window-manager kdeartwork kdeartwork-emoticons kdeartwork-style kdeartwork-theme-icon kdebase kdebase-apps kdebase-workspace kdebase-workspace-bin kdebase-workspace-data kdeeject kdelibs kdeplasma-addons kdeutils kdewallpapers kdf kfloppy kgpg khelpcenter4 kinfocenter konq-plugins-l10n konqueror-nsplugins kscreensaver kscreensaver-xsavers ktimer kwrite libgle3 libkde4-ruby1.8 libkonq5 libkonq5-templates libnetpbm10 libplasma-ruby libplasma-ruby1.8 libqt4-ruby1.8 marble-data marble-plugins netpbm nuvola-icon-theme plasma-dataengines-workspace plasma-desktop plasma-desktopthemes-artwork plasma-runners-addons plasma-scriptengine-googlegadgets plasma-scriptengine-python plasma-scriptengine-qedje plasma-scriptengine-ruby plasma-scriptengine-webkit plasma-scriptengines plasma-wallpapers-addons plasma-widget-folderview plasma-widget-networkmanagement ruby sweeper update-notifier-kde xscreensaver-data-extra xscreensaver-gl xscreensaver-gl-extra xscreensaver-screensaver-bsod
Installed using aptitude, removed with apt-get
ark google-gadgets-common google-gadgets-qt htdig kate kdebase-bin kdebase-data kdepasswd kfind klipper konq-plugins konqueror ksysguard ksysguardd libarchive1 libcln6 libeet1 libeina-svn-06 libggadget-1.0-0b libggadget-qt-1.0-0b libgps19 libkdecorations4 libkephal4 libkonq4 libkonqsidebarplugin4a libkscreensaver5 libksgrd4 libksignalplotter4 libkunitconversion4 libkwineffects1a libmarblewidget4 libntrack-qt4-1 libntrack0 libplasma-geolocation-interface4 libplasmaclock4a libplasmagenericshell4 libprocesscore4a libprocessui4a libqalculate5 libqedje0a libqtruby4shared2 libqzion0a libruby1.8 libscim8c2a libsmokekdecore4-3 libsmokekdeui4-3 libsmokekfile3 libsmokekhtml3 libsmokekio3 libsmokeknewstuff2-3 libsmokeknewstuff3-3 libsmokekparts3 libsmokektexteditor3 libsmokekutils3 libsmokenepomuk3 libsmokephonon3 libsmokeplasma3 libsmokeqtcore4-3 libsmokeqtdbus4-3 libsmokeqtgui4-3 libsmokeqtnetwork4-3 libsmokeqtopengl4-3 libsmokeqtscript4-3 libsmokeqtsql4-3 libsmokeqtsvg4-3 libsmokeqttest4-3 libsmokeqtuitools4-3 libsmokeqtwebkit4-3 libsmokeqtxml4-3 libsmokesolid3 libsmokesoprano3 libtaskmanager4a libtidy-0.99-0 libweather-ion4a libxklavier16 libxxf86misc1 okteta oxygencursors plasma-dataengines-addons plasma-scriptengine-superkaramba plasma-widget-lancelot plasma-widgets-addons plasma-widgets-workspace polkit-kde-1 ruby1.8 systemsettings update-notifier-common
Running apt-get autoremove made the results using apt-get and aptitude a bit more similar, but there are still quite a lott of differences. I have no idea what packages should be installed after the upgrade, but hope those that do can have a look.

Next.

Previous.