One of the common complains about Debian packaging is that it s hard to learn because, while there is quite a lot of high-quality documentation, it is often written more as a reference manual than as a tutorial: it s great if you already know everything and want to check some detail, but not so great if you want to learn everything from scratch. I have been volunteered (i.e, someone decided I volunteered) for a Debian packaging tutorial at work, so I decided to give a try at tackling this issue. I also volunteered (voluntarily this time) for a similar talk at RMLL 2011 to make sure I would be forced to do the work and prepare the actual tutorial. I m also considering teaching this next year in Licence Pro ASRALL, but I haven t made up my mind about it yet. The result is a work in progress (hey, I still have a lot of time), but in the release-early-release-often tradition, I m making it public now in the hope that someone will pick up the idea and do all the work for me (you never know). I ve decided to create a set of slides using Latex Beamer. The current version can be found here. The sources are available in a git repository, and all contributions are welcomed (including plain comments or suggestions). The last slide is the current TODO list.

A few weeks ago, I had an "out-there" idea to try creating and selling a site at the same time. So far, it's not exactly raking in a major amount of cash: At $100 with a couple of bids, it doesn't look like I'll be able to retire on it! That said, I haven't spent a great deal of time on it, and part of the idea of the experiment was to limit the amount of time the 'new idea' would distract me from other things. I did hope to receive a few more "audience requests" in terms of what to build on Flippa.com, though. Hopefully, things will heat up a bit during the final two weeks of the auction, but I don't think "flipping" web sites is really a business I want to be in. It's been fun to see how much you can build with how little, though, what with all the widgets and API's out there these days. Since I'm a coder at heart, I also released some Ruby code that utlizes Google's stock screener API: https://github.com/davidw/google-screener - it's under the Apache license, and is kind of neat to play around with, I think, and is what I use to fetch information for the site.

As you know, I very often advocate using the bycicle as the main means of transportation in Mexico City. The city is very apt for biking through it, and contrary to the fears of mostly everybody, the city is neither aggressive nor as dangerous as people say. However, I have seen cyclists which seem to be looking for the best ways to be hit by a car, or to hit a pedestrian. Yesterday, I read this note in La Jornada: The local Environment Secretary calls cyclists to respect vial regulations. Many cyclists assume they are a special case of pedestrians, and zig-zag as they please between the road and the walkway, or just stay in the walkway. That is dangerous, both to pedestrians and to themselves. You might find children, elderly or motion-challenged people on your way. Also, not only will pedestrians only expect other people in the walkway, moving at their pace or slightly more, but cars will also not expect somebody moving at 10-20Km/h. A car driver pulling out of his garage, or crossing a street, will not have enough warning when he sees you, and you are very likely to end up in an accident. Since ~5 years ago, Mexico City is growing a grid of Metrob s and confined troleb s cero emisiones (trolleybus) lanes. Many cyclists use those lanes That is VERY dangerous. Public transport vehicles are large, have a lot of inertia, and will take longer to react to finding you ahead of them. Besides, they can go way faster than a regular bike (~60Km/h for metrob s, ~40Km/h for troleb s), and have to stop every couple of blocks. So, you will be uncomfortable if trailing them, and you will be a liability to ~100 people if you go ahead of them. Besides, it is illegal to drive in the confined lanes if you are not a public, semimassive transport vehicle! Surprisingly many people have argued they prefer riding their bicycles against the traffic I think they prefer staring at Death into its blue, glowing eyes (or into its long, thin whiskers)... By far, most cars that hit a bicycle do so from the side, when crossing a road. And if you arrive at a crossing from the wrong way, the way a driver does not expect you, don't expect the driver to be aware of you. Also, in the much less likely event of a car running into you, would it be better to be hit at 80Km/h (60Km/h of the car plus 20Km/h of your own speed on a full frontal crash), or at 40Km/h (substracting instead of adding)? Yes, some people say that looking at the car will allow you to maneuver How far in advance would you know a car coming from the front will hit you? One second? That's 22 meters at 80Km/h (again, if you realize the 60Km/h car is heading straight to you, at 20Km/h). Too short notice for you to do anything Any maneuver will most likely end in an accident. And the driver would not be so much to blame, as he would not be anticipating you riding against the traffic. Make sure you get seen. By night, always use proper lights (red on the back, white on the front, and reflective material to the sides). Day or night, wear bright, reflective clothes (or over-clothes material). Act in a predictable fashion. Remember you are riding a vehicle and are subject to the same rules any driver is A cyclist is not exempt from driving correctly! Do not jump red lights. Never ride on the walkway. Do your best to enjoy the ride. And ride. Yes, ride, take the streets, enjoy the streets. But don't attempt to drive the traffic out of it The streets belong to us all, and we can all share them. PS I also saw this note in the same paper: Sunday Rides in "Campo Militar N mero Uno". The main military field was open as a park this weekend! I have to make sure it is regularly open I am definitively going there!

We still have more than 300 new packages in Debian that needs manual checks and we have a lot of open bugs. I don t get paid for working on dak (the Debian Archive Kit) nor do I feel a deep passion on doing such work. I am contributing to Debian because it is a great project and because contributing is my way to say Thank you to all who made (and still make) it possible. BUT: are we slaves that are supposed to do any stuff for other people? Yesterday someone asked for an enhancement for dak via IRC. I ve kindly asked him: do you want to send a patch? (words are copied from the IRC session). Instead of answering no he sent a patch for 2 plain text files within 4 minutes after I told him the URL to dak s git repository. I could not do it faster by myself and I ve got many other open tasks. I ve applied the patch and activated it on ftp-master.debian.org. But today he ranted about my rudeness and he did not even managed to quote me correctly ( Please send a patch ).

It seems that Matthew Palmer misread my blog post as a complaint against developers asking for patches in exchange of pet feature requests. He really should pay more attention, since I gave pet feature requests as an example of case where it would be appropriate to ask for a patch:

Of course, there are cases where it s perfectly reasonable to ask for a patch: when the task is expected to take hours, or when the result is of limited interest to everybody except the demander.

But even then, it s not clear. This morning I got an email from a someone involved in PHP packages maintenance, who said that Bugs Search @ UDD was a great tool, but that he would love to have a way to list all bugs affecting packages with the implemented-in::php debtag.
To produce a working patch for this would probably take him at least an hour. You need to set up a copy of the CGI on alioth, understand the DB structure, dig into the code, etc. If you don t understand SQL and Ruby, it could be a really difficult process. Also, it s probably quite uninteresting for him to do that, since he is unlikely to stick around developing UDD.
Instead, it didn t take me more than 5 minutes to produce a one-liner.
The net result for Debian in that case? 55 minutes saved by a developer. Update:
Torsten Werner wrote an angry reply to my post. It s true that yesterday s episode triggered my blog post, because I felt quite frustrated to have to provide a patch for something that simple, and would have preferred to use the time for a Debian task where I would be more efficient. But I was not particularly angry at that episode, since that s something I ve seen on several occasions. That s also why I did not mention any team in particular.
The feature request I was making was reasonable, and cannot really be considered a pet feature request (though I might be biased with my QA hat on): mentionning in the dak templates used for bug closure that packages removed from Debian can still be found on snapshot.d.o. The fact that he thinks that addressing this himself turns him into a slave raises interesting questions.

On the gripping hand, Matthew, notice that patches written by someone utterly unfamiliar with the code in question aren't always welcome. While some people don't mind spending several days on something that may or may not be accepted to begin with, it's important to realize that talking about wishlist items before even thinking about possibly writing a patch is more likely to result in the desired behaviour than writing and submitting patches in a fire-and-forget manner. In that light, there are cases where 'please send a patch' can be quite demotivating, and it makes sense as a developer to engage in a discussion about a wishlist item, even if you're not immediately interested in implementing said feature yourself. Such a discussion could lead to either you implementing it, or someone else implementing it, or the other person finally understanding that your vision for the software in question doesn't match theirs, and that they should just find something else to spend their time on. I guess the moral of the story is: as a user with a wishlist item, you should talk to developers, let them know what you think is important, and be prepared to write a patch yourself if needs be and you have the skill. As a developer, you shouldn't interpret every wishlist request as a question to 'please please please implement my pet feature', but as an opportunity to reconsider your views, and possibly implement some nice new feature that you hadn't thought about originally but which you think might be nice, too. If people reply with 'please provide a patch' to each and every wishlist request, they're stupid; even more so than users who think they have anything to demand.

On the other hand, Lucas, remember that each time you ask someone to take some time to implement your pet feature request, you take some time away from her that could be used to contribute something in an area where she gives a damn. (This has been a Public Service Announcement from the "Scratch your own itch" foundation, with the grateful assistance of the "Paddle your own f**king canoe" committee.)

There s a frequent pattern in the Debian community where someone would suggest an improvement to some package or service, and the person responsible for it would reply with please send a patch . Of course, there are cases where it s perfectly reasonable to ask for a patch: when the task is expected to take hours, or when the result is of limited interest to everybody except the demander.
But often, it would be much more efficient for the person responsible for the service to take 5 or 10 minutes to make the change, than for the demander to spend half an hour learning how to contribute to this service, writing an untestable patch, and sending it back to the person responsible for the service for integration. It is important to see this problem as the issue of maximizing the usefulness of the resources we have. Often, we are in a situation where we could either:

• spend 30 minutes on a service we don t know, just to push one change
• spend 30 minutes making three or more changes that others would like to see in a service we know

It would be much better if, instead of saying Please send a patch , people would say Are you interested in contributing a patch, or should I make the change myself? . Remember that each time you ask someone to take some time to contribute a patch in an area where he is not an efficient contributor, you take some time away from him that could be used to contribute something in an area where he is efficient.

Yes. And, I m talking about Localization in Localization foo talk. Speaker list is awesome. See you there! * List of talks: http://kde.in/conf/talks/
* Delegate registration: http://kde.in/conf/register/ In case, you re in Ahmedabad or near by (and college student!) , I ve awesome posters to put into your college notice board to let your friends and spread the word. Ping me that case.

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

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

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

This is a wonderful beginning of the week. I ve lost my n900. Most likely, case was not properly mounted on my belt today, and fell down at some point. Chance to get device back is near-zero. It does not respond to calls to itself ( off or out of network coverage ) so likely somebody found it, and turned it off and/or replaced SIM, etc. I ve used it for more than a year. It had lots of customizations, large chat logs, and lots of other data. And it was tightly integrated into my day-to-day life.
Some backups are available but not very recent. And not sure that these backups could be used to recover things into other device and, given all those recent news about Nokia, it is definitely unwise to buy a new n900, as well as any other Nokia device. This blog will unlikely get any more n900-related posts. I m quite frustrated, and can t do anything useful already for several hours .

As much for my own reference as anything else... I quite often use vmplayer on my work desktop, and occasionally on my laptop. Other options might work better for other people, but the company have already settled on using vmware on their Linux machines to give users access to Outbreak, Office etc. I try to avoid them as much as possible, but about the only effective option for calendaring at work is Outbreak. *spit*. And on my laptop, I just have a vmplayer setup containing a trivial Windows XP installation for things like Nokia firmware updates. It's more hassle than I can be arsed with to move to something else - the only thing worse than using Windows is installing it, in my experience. In most respects, vmplayer is working OK for me. But: it has one intermittent and really annoying bug. Every now and again, as I switch away from the vmplayer session to another desktop using Ctrl-Alt, then Ctrl-Alt-Cursor, vmplayer eats the state of the X keyboard modifier keys. This makes things interesting after that point: my normal use of emacs, firefox, xterms, mutt (etc.) is fairly heavily dependent on being able to use the Shift and Ctrl keys. This looks like it has been documented as a bug in a number of places over the past few months/years (1, 2, 3, 4, etc.) but there doesn't seem to be a fix coming. However, what I have found out is that there is a workaround: setxkbmap will reset the modifier key state when things have broken. If only I'd been able to find that earlier - I've ended up restarting X or rebooting in the past... :-(

Sponsoring a package means uploading a package for someone else (usually a new contributor starting out as package maintainer). This is an activity reserved to Debian Developer who are supposed to be knowledgeable about packaging. This article tries to document the process to ensure the sponsor is doing a reasonably good job according to Debian s standards. Sponsoring a package in the Debian archive is not a trivial matter. It means that you verified the packaging and that it is of the level of quality that Debian strives to have. Let s have a look to what you can and should do when you re sponsoring a package. Sponsoring the initial upload Sponsoring a brand new package into Debian requires a thorough review of the Debian packaging. Building the package and testing the software is definitely not enough! You should open every file in the debian directory and look out for potential problems. Here s a checklist that you can use to perform the audit:

• Verify that the upstream tarball provided is the same that has been distributed by the upstream author (when the sources are repackaged for Debian, generate the modified tarball yourself).
• Run lintian. It will catch many common problems. Be sure to verify that any lintian overrides setup by the maintainer is fully justified.
• Run licensecheck and verify that debian/copyright seems correct and complete. Look for license problems (like files with All rights reserved headers, or with a non-DFSG compliant license).
• Build the package with pbuilder (or any similar tool) to ensure that the build-dependencies are complete.
• Proofread debian/control: does it follow the best practices? are the dependencies complete?
• Proofread debian/rules: does it follow the best practices? do you see some possible improvements?
• Proofread the maintainer scripts (preinst, postinst, prerm, postrm, config): will the preinst/postrm work when the dependencies are not installed? are all the scripts idempotent (i.e. can you run them multiple times without consequences)?
• Review any change to upstream files (either in .diff.gz, or in debian/patches/ or directly embedded in the debian tarball for binary files). Are they justified? Are they properly documented (with DEP-3 for patches)?
• For every file, ask yourself why the file is there and whether it s the right way to achieve the desired result. Is the maintainer following the best packaging practices described by the Developers Reference?
• Build and install the packages, try the software. Ensure you can remove and purge the packages. Maybe test the packages with piuparts.

If the audit did not reveal any problem, you can upload the package. But remember that even if you re not the maintainer, the sponsor is still responsible of what he uploaded to Debian. That s why you re encouraged to keep up with the package through the Package Tracking System. Sponsoring an update of an existing package You will usually assume that the package has already gone through a full review. So instead of doing it again, you will carefully analyze the difference between the current version and the new version prepared by the maintainer. If you have not done the initial review yourself, you might still want to have a more deeper look just in case the initial reviewer was sloppy. To be able to analyze the difference you need both versions. Download the current version of the source package (with apt-get source) and rebuild it (or download the current binary packages with aptitude download). Download the source package to sponsor (usually with dget). Read the new changelog entry, it should tell you what to expect during the review. The main tool you will use is debdiff, you can run it with two source packages (.dsc files), or two binary packages, or two .changes files (it will then compare all the binary packages listed in the .changes). If you compare the source packages (excluding upstream files in the case of a new upstream version, for example by filtering the output of debdiff with filterdiff -i '*/debian/*'), you must understand all the changes you see and they should be properly documented in the Debian changelog. If everything is fine, build the package and compare the binary packages to verify that the changes on the source package have no unexpected consequences (like some files dropped by mistake, missing dependencies, etc.). You might want to check out the Package Tracking System to verify if the maintainer has not missed something important. Maybe there are translations updates sitting in the BTS that could have been integrated. Maybe the package has been NMUed and the maintainer forgot to integrate the changes from the NMU in his package. Maybe there s a release critical bug that he has left unhandled and that s blocking migration to testing. Whatever. If you find something that she could have done (better), it s time to tell her so that she can improve for next time. And so that she has a better understanding of her responsibilities. If you have found no problem, upload the new version. Otherwise ask the maintainer to provide you a fixed version.

---

This article will be repurposed to enhance the Debian Developers Reference, hopefully leading to a fix for the wishlist bug #453313. Click here and help me fix more of those. You re also welcome to suggest improvements in the comments. Are there other checks that you re always doing? Do you have some handy tip to make it easier to review a package?

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

The conference LCA 2011 had an anti-harassment policy [1] which was violated by a keynote speech. The speaker and the conference organisers apologised, but of course the matter didn t end there.Discussion continued on the lca-chat list (for conference delegates) [2], on the Linux-aus list (for members of Linux Australia the parent body of the LCA conference) [3], and in some blog posts.There is also some discussion on an LWN article that is linked from an ITWire article [4].I think that the policy was reasonable and from all the descriptions it seems to have worked reasonably well. With such things there are always possibilities to tweak things, so probably there will be future policies which are better in some ways, but it seemed to do the job. The way that the LCA organisers handled the situation was appropriate. In the discussion there were some comments with logical failures that I think need further analysis, I ll summarise them one per paragraph with the heading being a para-phrase of the claim.Is it Offensive?A particularly relevant blog post is Skud s post about avoiding the use of the word offense [5]. In the various discussions about the speech in question most of the people who disapprove of the erotic images don t use the word offense , this is presumably due in part to the influence of Skud s post. This hasn t stopped people claiming that the debate is about whether the images are offensive, I m not sure if this is a deliberate straw-man attack or just cluelessness.The anti-harassment policy does use the word offensive in two places, I think that this was a mistake but it doesn t detract from the overall meaning of the document.Is it Harassment?There was some discussion about whether the actions in question were harassment. Wordnet s definition of harassment includes the act of tormenting by continued persistent attacks and criticism . It seems unlikely that any of the people in the audience who objected to the erotic content in the lecture slides had never seen unwanted erotic material before. So I think that it s worth considering this incident as just another entry in a list of similar incidents that some of the delegates have experienced, and thus as a continuation of persistent attacks IE harassment. Melissa McEwan s post about the variety of harassment that she has received from men is worth reading in this regard [6].I think that a reasonable analogy here is the school bullying campaigns that were experienced by many members of the Linux community when they were younger. School bullying in most cases is not about a small number of extreme incidents, but about a large number of small incidents each of which when considered independently can be rationalised as something that isn t significant (excusing such incidents independently is what allows bullying to be rife in most schools). In many cases of high school bullying the victim is blamed for supposedly over-reacting after a reaction is compared to some small incident at the end of a long harassment campaign, some of the criticism of the Geek Feminists seems to echo this pattern.It seems to me that some of the more dismissive comments which demonstrated a lack of regard for the experiences of other people can reasonably be considered as harassment too (which is also something that Melissa McEwan mentions). Note that I am specifically not advocating that the discussion be shut down, merely that the people who claim that it s only the (supposed) opinion of the majority that matters are part of the problem. However the fact that the apology for the talk received applause from the majority of the audience seems to indicate that the majority is in fact in favor of the anti-harassment policy.Derald Wing Sue, Ph.D. and David P. Rivera (a doctoral candidate in counseling psychology) have written a couple of interesting short articles about this for Psychology Today. Bullying and Microaggressions describes bullying as more than physical violence and also discusses adult bullies [7]. The Power to Define Reality describes the way that the experiences of people who lack power can have the reality of their experiences denied [8] this one really relates to some of the discussions about harassment.But it s Legal!It has been claimed that the legal system works well in Australia and that Australian law should be the only necessary guide to content. A trivial counter-case that was noted in the discussion is the fact that pure sales presentations are not accepted at LCA and such presentations are certainly legal! There is a good precedent for prohibiting things that are legal as part of the conference speaker agreement.More generally the legal system changes slowly and still infringes on what many people in our community regard as basic human rights. There is no reason why an Australian conference should have as it s standards the bare minimum that is required by Australian law.It was pointed out that workplace social norms translate well between cultures, they are usually more stringent than Australian law requires and Australian workplace law is a lot more stringent than the laws relating to conferences and other public events. It seems to me that a presentation which would result in a visit from HR if given at the office shouldn t be regarded as suitable for a conference such as LCA.But there is a Balance of Men and Women in Erotic Pictures!The complaints are not about a lack of balance in the erotic material, but it s presence there at all. Defending the slides on the basis that there was a supposed balance of male and female misses the point that most people just want no erotic material in presentations at conferences.Also it seems to me that if there are pictures which aren t offensive then the way to demonstrate this would be to publish them and say look, they aren t offensive . If it takes 600 words in a blog post to justify the use of some images then that alone seems to be evidence that the images were poorly chosen.But the talk was EffectiveSome of the people who have commented on this issue mentioned that they couldn t remember what was said when the images in question were displayed. When images from the talk are remembered and the main content of the talk isn t that seems to be a failure of the talk.When a major sponsor of the conference complains and requests that the talk video never be published that also seems like a major failure of the talk.I think that the effective talks are ones that educate people and inspire them to do something positive and useful. A talk that inspires a discussion about whether the speaker deserves censure doesn t seem effective.There are claims that there is no way the talk could have made the point as well if it wasn t for the images in question. But I can t believe that someone who is capable enough to get awarded a keynote speaking position at a conference such as LCA is incapable of finding other images to make the same point.But Similar Images are on MTVWhen people want MTV content they can watch MTV.Why Can t we just try Educating Men?It was claimed that education works in dealing with such issues in corporate environments and sporting clubs. My observation of the corporate environment is that such training must be extremely rare in Australia, the Netherlands, and probably the UK due to the fact that none of my employers have done it. I have heard first-hand reports of diversity training from people who work in the US. I expect that the fact that people who fail diversity training in a corporate environment get a meeting with HR is a major factor in it s effectiveness.The long email discussions and blog comment threads when these incidents happen could theoretically be used as training. But when you have some men using multiple mailing lists and dozens of posts arguing without appearing to learn it seems clear that they are not about to learn anything no matter what education is offered. It seems to me that you could broadly divide the free software community into two groups, those who want to learn how to do things better (but who are unlikely to make gross errors anyway), and those who won t learn.Besides, having a keynote speaker at a major conference apologise should be educational.But Clueless Nerds Hit on GirlsI don t know why every discussion about the treatment of women ends up getting a mention of this supposed issue.But Women Could make False AccusationsIn any classification system you have to make some sort of balance between false-positives and false-negatives. If the aim is to get zero false-positives then the incidence of false-negatives will increase. So if the aim was to never ever have a false accusation brought against a man for sexual harassment then the vast majority of real harassment cases would result in no action at all.I don t think it s reasonable to expect that most women who are mistreated should suffer in silence just to reduce the possibility that men might be falsely accused.The Rape Statistics cited in the discussion may be InaccurateThere is no possible way of interpreting rape statistics to make it not be a serious problem, now matter how you analyse the available information it happens far too often and has a significant impact on the victim. Also the suggested reinterpretation of the statistics didn t contradict the claim that it is likely that there are multiple rape victims attending LCA. So interpreting the statistics in a different way to get different numbers doesn t change anything. Trying to diminish the significance of rape generally doesn t support any other arguments that you might make.There are things that you can just discuss for the heck of it and things which should be discussed with care (if at all) to avoid needlessly hurting people. In these sorts of discussions the right thing to do is to avoid debating the numbers as much as possible.I think that the numbers produced by RAINN [9] are as good as we can get.But I am very supportive of women in our communityIf you spend all your time arguing with women and don t listen to what they have to say then you really aren t supporting them.ConclusionAfter publishing this post I ll email the URL to a few of the men who helped inspire it, I will explain how disappointed I am and how I expect better from them. I encourage others to do the same.Also when such discussions happen I encourage men to vote in favor of the positions advocated by women. Writing a message that addresses points in the debate can be difficult and if the debate is rapid then you may find that every point that you might make has been made by someone else. But in that case just posting to agree with the women can really mean a lot.

• [1] http://lca2011.linux.org.au/about/harassment
• [2] http://lists.followtheflow.org/pipermail/chat/2011-January/001722.html
• [3] http://lists.linux.org.au/pipermail/linux-aus/2011-January/018431.html
• [4] http://www.itwire.com/opinion-and-analysis/open-sauce/44803-linux-australia-members-abused-over-pesce-keynote?start=1
• [5] http://infotrope.net/2009/08/05/action-and-reaction-on-avoiding-offense/
• [6] http://shakespearessister.blogspot.com/2009/08/terrible-bargain-we-have-regretfully.html
• [7] http://www.psychologytoday.com/blog/microaggressions-in-everyday-life/201101/bullying-microaggressions
• [8] http://www.psychologytoday.com/blog/microaggressions-in-everyday-life/201010/the-power-define-reality
• [9] http://www.rainn.org/

Now that maintain several dozens of packages in Debian, I think twice before uploading a new one. Does it have a future, a public ? Some of the packages I prepare are available on git.debian.org, and are listed in Debian Med's tasks pages. It would not take me long to finish most of them, but that does not take into account the time others will spend on it. They will make our archive bigger and our quality tests longer to execute. Somebody will translate their description. Somebody else will perhaps write a security patch someday, or a patch to make the package compilable with a new version of GCC. All in all, each package has a footprint in Debian's ecosystem. That footprint starts early, as soon as the package is sent to the NEW queue. For instance, I kept by mistake some old content in the copyright file of clustalw, that was recently freed and has to go through the NEW queue to be transferred from the non-free to the main area of our archive. That costed a small of exchange of emails, that could have been avoided. Our packages should be perfect, but that is difficult to achieve alone. For that reason, I proposed two years ago a package review system, that functions like a chain reaction. The principle is simple. After uploading to the NEW queue, download two neighbor packages and check their copyright file. The errors found can be corrected by their maintainer before the the FTP team inspects it, which save their time. For instance, after uploading tabix, I found an error in mediathekview, that was corrected. That compensates for my mistake with clustalw. If each person receiving a package review does a review of two other packages, that will create a chain reaction that will clean the queue from the simplest mistakes, leaving only the really problematic cases. As Torsten noted recently, the NEW queue is getting long. So how about trying to help ?

In Bits from the Security Team a few weeks ago, Thijs Kinkhorst wrote:

Since a couple of years we ve been handing off security issues of minor or
theoretical impact but for which a fix would be desirable at some point, like
certain classes of denial-of-service attacks, off to stable point updates.
We re looking for a person that wants to coordinate this: monitor the Security
Tracker for issues classified as such by the Security Team, converse with
maintainers to get such updates done and coordinate with the stable release
managers on this.

I m happy to confirm, now that it s been announced, that I am that person: point release security co-ordinator. Affected packages If your package fulfils these criteria:

• it had a security problem reported in the past (that is, it was allocated a CVE number);
• it didn t get a Debian Security Advisory, but it wasn t marked unimportant in our tracker;
• it has been fixed in unstable, but the version in stable or oldstable is still vulnerable

it is a candidate for updating in stable or oldstable, and you ll probably receive a mail from me at some point asking you to do so. You can pre-empt this mail of course, by backporting your fix to the affected versions and contacting the release team to get your fix into stable, without waiting for me. In such a case, please drop me a note with the details so I can tick your off on my hit^W candidate list. Making a stable/oldstable upload This is documented in the Developer s Reference, but to summarise:

1. Prepare your fix, targetting stable or oldstable, and build it in an up-to-date chroot for that release
2. Send a diff of the new package to the release team, asking for permission to upload
3. Upload as normal, and wait for it to be included in the next point release. Meanwhile, notify the security team of your upload, if it fixes a CVE.

Tracking candidate packages I m going to start off tracking filed bugs for SPU candidates and OSPU candidates with usertags in the BTS, under my own address. In time that might be merged into an address used by the security team, but for now I m still finding a good workflow so it s much easier this way.

---

Point Release Security Co-ordinator is a post from: jwiltshire.org.uk Flattr

A while ago (early 2009), I created whiteboard.debian.net as a way to do real-time editing collaboration. While working for DebConf, I really wanted to be able to collaboratively edit text with people, and all of the web-based solutions I found at the time were non-free. Thus, I took mobwrite and wrote a very thin wrapper around it. Mobwrite is where all the cleverness is (and mobwrite is way beyond my expertise, by the way). Mobwrite is Apache licensed, so you can use it in other places, too.Thus, whiteboard.debian.net was begun. It was never publicized very much. It has no authentication required and no history (the "static link" does provide limited recovery for mistakes, though). Here is a test whiteboard; open it in two tabs and watch the text areas sync. Any whiteboard is created if you go to a valid URL.I just deployed a slightly newer version of whiteboard. You can now see an options page for each whiteboard, and it can render in several lightweight markup languages (good for drafting+previewing things). If you have other options to add there, let me know.If you are interested in collaborative text editing, there are some other options. There is a Debian titanpad, an "open" instance of now-open-sourced Etherpad, and it has history support. Use titanpad.com and you don't have to log in. Here is a test pad. For a non-web application, Gobby exists. Use gobby-0.5 for smart undo history if everyone uses squeeze or above.Is whiteboard still relevant in light of the options above that store history? I'm sure it depends, but for now, whiteboard works well for a low-overhead scratch space and for cases where you don't want to have a history trail. I also tend to use it as a simple pastebin or a personal notepad when I don't want to worry about having traces left behind. In short, it is so minimal you don't have to think about starting one up for something. I have found that collaborative writing really helps to get things done, thus, I hope that whiteboard (or a similar tool) can be useful to you.

Here comes the forth Debian XSF News issue! I usually try to keep the items sorted chronologically (but grouped by topic when possible), so if you re wondering about the current status of X in unstable, make sure you read the last entry.

• I prepared a reference documentation about dependency handling between the X server and the drivers. It describes both upstream and Debian sides, and documents the mechanisms to get the dependencies right. If you maintain an input or a video driver for X, you really should have a look into it.
• I also announced the changes on debian-boot@ since the Graphical Installer is also concerned.
• Since there are some drivers which aren t maintained by the X Strike Force, I mailed almost all maintainers (plus the ones I missed) to keep them posted. Further coordination will go through a mail alias (which means a little less overhead than running a mailing list; mail me if you want to be added).
• I prepared a great clean-up of the drivers, and published a status report 3 days later.
• In order to keep track of people working on X packages these days, I started pinging the Uploaders of X packages. Thanks again, folks!
• On the driver side, I moved the xserver-xorg-video-dove driver to the attic (where we move repositories of unmaintained packages), since it was only ever uploaded to Ubuntu, and not really maintained upstream. I also moved 7 drivers there, and requested their removal through RM bugs (each bug contains a link to the git repository in the attic in case someone wants to revive a driver): xserver-xorg-input-citron, xserver-xorg-input-evtouch, xserver-xorg-input-fpit, xserver-xorg-input-hyperpen, xserver-xorg-video-nv, xserver-xorg-video-radeonhd, xserver-xorg-video-v4l.
• Julien Cristau also requested the removal of xprint and xprint-utils. He also orphaned xresprobe since it s of no use as far as X is concerned, but still seems to be of some interest to DebianEdu folks.
• I requested an update of debian-x@ s description. We haven t been doing any Debian XFree86 packaging in a while.
• I requested help from GNU/kFreeBSD and GNU/Hurd folks, and got replies from Petr Salinger and Dave Airlie. Now mesa builds again on kfreebsd-amd64 (and kfreebsd-i386 once the remaining glitch is fixed).
• In the same mesa upload, I enabled the r600 Gallium driver, and cherry-picked a commit to fix the crash at X s start-up with r300 and UMS.
• I merged the xsf-docs.git repository (source for XSF documentation at http://pkg-xorg.alioth.debian.org/) into the xorg.git one, and moved the former to the attic. Starting with xorg/xserver-xorg 1:7.6+2, XSF documentation is shipped in the xserver-xorg package, in the /usr/share/doc/xorg directory, in HTML, PDF, and TXT formats.
• I also added a bug control file (as documented in reportbug s README.developers) to xorg, telling reportbug to also report information related to the xserver-xorg package. This means we get xserver-xorg-core s version, along with the drivers. I also made xorg depend on xserver-xorg with the same version, to make sure that upgrading xorg means upgrading xserver-xorg as well (and xserver-xorg-core ultimately, since xserver-xorg pulls a given version of the server).
• Julien also uploaded a few libraries and mesa-demos (new source package for mesa-utils) to unstable. I also uploaded the latest pixman to unstable.
• A few hours before squeeze got released, I prepared the big move of the X server from experimental to unstable. For the record that meant uploading libdrm, libxfont, and mesa as prerequisites. I then pushed the locally-built packages in a local archive to use from my sbuild chroot, to get xorg-server built. Subsequently, I built 45 drivers against it. The xorg metapackage was also prepared. All in all, that meant 200MB worth of Debian packages (including 130MB for mesa alone ), which sat on ravel.debian.org until the squeeze release announcement. Unfortunately, lintian s #612137 triggered an automated rejection of all drivers. Options seemed to be: adding build dependency noise to debian/control for all drivers; or adding lintian-overrides noise to all drivers; or waiting for some reaction from lintian s maintainers or from ftpmasters. I picked the last option for now, since I m very reluctant to do extra and pointless work on 45 packages to get them accepted when the reason for the rejection is buggy. Hopefully this will be sorted out soon, and I ll be able to upload the same packages again. If one feels the urge of installing X11R7.6, picking drivers from experimental will do the job.

mythbustering a Debian release This is no news anymore, but in case you don't know yet: Debian 6.0 "Squeeze" has been released the past week-end. If you haven't yet downloaded Squeeze, stop reading this blog post right here and jump to: to choose your ISO; or check the release notes for upgrade instructions from Debian 5.0 "Lenny". Done?
Cool!
I hope you are now enjoying Squeeze as much as I've enjoyed being part of its development cycle which:

• has lasted 24 months from the Lenny release
• has been worked on by a volunteer Project of about 900 members and thousands of other volunteer contributors
• has closed 150'000 bugs
• has increased user freedom by delivering a Free Linux kernel
• has added 2 non-Linux ports (kfreefbsd 32/64 bits) to the already large family of Debian ports
• will continue the tradition of archive-wide long term security support (lasting about 3-3.5 years given current Debian release cadence)
• maintains, stubbornly, the tradition of a rock-solid Debian-quality system, made of packages which have been "tortured" by testing utils like piuparts, edos-debcheck, and frequent archive rebuilds (after all, what is Free Software for if you cannot recompile your programs?)
• has added 10'000 new (binary) packages
• has provided official backport service
• ... etc, you got the idea

I'm still shaked by the events, given the release happened in a sort of split context: the teams working on the final phases of the release (release team, ftp-masters, webmasters, cd, DSA, etc.) were "at home" hacking frantically on it, while many EU-based Debian people (including yours truly) were at FOSDEM representing Debian to the community with booth, talks, and answering the recurrent question so, have you released yet? . At FOSDEM, I've been personally submerged by congratulation messages that are not really for me, but rather for the Debian community at large. So: congratulations folks! People out there be them Debian users, users of some derivative, or Free Software enthusiasts in general seem to really love what we have achieved with Squeeze! The people that need to be thanked for this result are way too many, so I won't try to name names. Nonetheless, I've a few personal kudos to deliver to:

• The release team for the fantastic coordination and communication job over the past few months. They have also contributed to mythbustering #1: Debian cannot fix a release date (a bit) in advance.
• All the people who have worked on fixing RC bugs by sending patches, reviewing and testing them, preparing NMUs, etc. I'll never give up my belief that releasing is a shared responsibility and that we cannot scale without realizing that and changing our culture accordingly. All this people have contributed to move towards mythbustering #2: NMUs are bad.
• The publicity team which with release live blogging via @debian, blog posts, and press releases have contributed to mythbustering #3: Debian isn't able to communicate about the "cool" stuff they are doing.
• The webmaster team which has done an incredible job at mythbustering #4: Debian web presence sucks.

I'm overwhelmed by happiness about all that and I'll cherish it forever as a souvenir of what a community of volunteers, driven by common ideals, can achieve. Now let's party and then roll up our sleeves for Wheezy, which is already open for development.

---

PS I've talked again at FOSDEM about the relevance of Debian in the Free Software ecosystem. I've the impression the message is getting through: check out the very nice article Why Debian matters more than ever by Zonker.

Squeeze was released this weekend and it's time to slowly migrate servers to it. The first to upgrade came the ones backing up phpMyAdmin demo server. Reason for trying them first is they have mostly same setup as other, while definitely not being critical to run all the time. For simple reasons that users break them time to time as well :-). Everything went surprisingly smoothly, the only problematic thing being no availability of MariaDB packages for Squeeze right now. But it does not matter that much, as Lenny packages still work fine. There should be no visible changes on the servers, but in case there is something broken, please let me know. While having experience with upgrading database servers, I went to production database server and it is now running Squeeze as well. What still remains is the server doing virtualization, but I prefer to do this in time when I can quickly get to the housing, in case something goes wrong with the reboot.

Filed under: Debian English Phpmyadmin 0 comments Flattr this!