Recently I thought a lot about group building. There had been some dynamics going on in way to many communities that I am involved with, and it always came down to the same structural thing:
Is the group welcoming participation of everyone?
Is the group actively excluding people?
When put this way, I guess most people will quite directly swing towards the first option and outrule the second. Thing though is, it's not that easy. And I'd like to explain why.
Passive vs. Active Exclusion
The story about passive exclusion
Exclusion always happens, it even has to happen, regardless how you try to form a group. Let me explain it by an example, that recently happened at an event in Germany. It was an event called "Hanse inter nichtbinär trans Tagung (HINT)", conference for inter, non-binary and trans folks. A doctor was invited who performs genital "corrective" operations on babies, something that inter people suffer a lot and unfortunately is still legal and a huge practise around the globe while there is no medical need for any of this. In turn inter people didn't feel safe to attend a conference anymore that was specifically set out for them as part of the target audience.
And that's just one example. I could come up with a fair amount of others, like having sexual abusive people at polyamory meetups, and there is a fair amount of free software related discussions going on too, having abusive people in the community actively invalidating others, ridiculing them, belittling them, or software that specifically enables access to hate-speech sites on free software portals, all with the reasoning that it's about free software after all.
All these things lead to passive exclusion. It leads to an environment that suddenly doesn't feel safe for a fair amount of people to get involved in in the first place. People that are claimed to be wanted within the community. People who are told to grow a thicker skin. People who are criticized for pointing out the discrimination and being rightfully emotionally wound up, also about the silent bystanders, having to do the emotional labour themselves. And as organizers and group leads, it's definitely the less energy consuming approach.
When you understand this, and start to engage with abusive people that make other feel unsafe, you might realize: That's actually hell of a work! And an unthankful one on top of that. You suddenly have to justify your actions. You will receive abusive messages about how could you exclude that person because they never have been abusive to them so it can't be true, you are splitting the community, and whatsnot. It's an unthankful job to stand up for the mistreated, because in the end it will always feel like mistreating someone else. Holding people accountable for their actions never feels good, and I totally get that. That's also likely the reason why most communities don't do it (or, only in over-the-top extreme cases way too late), and this is a recurring pattern, because of that.
But there are these questions you always have to ask yourself when you want to create a community:
"Whom do I want to create a community for, whom do I want to have in there - and what kind of behavior works against that? What am I willing to do to create the space?"
When you have a clear view on those questions, it still might be needed to revisit it from time to time when things pop up that you haven't thought about before. And if you mean it honest, for a change, start to listen to the oppressed and don't add the hurt by calling them out for their reaction of fighting for their sheer existence and survival. Being able to talk calmly about an issue is a huge privilege and in general shows that you aren't affected by it, at all. And doesn't contribute to solving the discrimination, rather just distracts from it.
Middle ground?
One last note: Active exclusion doesn't necessarily have to happen all the time. Please check in with the abused about what their needs are. Sometimes they can deal with in a different way. Sometimes the abusers start to realize their mistake and healing can happen. Sometimes discussions are needed, mediation, with or without the abused.
But ultimately, if you want to build any inclusive environment, you have to face the fact that you very likely will have to exclude people and be ready to do so. Because as Paula said in her toot above:
"If you give oppressors a platform, then guess what, marginalized people will leave your platform and you'll soon have a platform of dicks!"
It seems almost as if being political correct is something people do not want to be. As a matter of fact, to move forward as humanity, we though need it very much. Let's take a look at the why and what it actually means, shall we?
I think we all have heard of the Golden Rule: "The Golden Rule is the principle of treating others as one's self would wish to be treated." I hope that we can agree on that. The idea behind is to envision oneself in the other person's shoes, figuratively, and see what it would do to yourself. If you don't like it, don't do it. Sounds easy?
Well, it isn't. When it comes to discrimination, which is something systematic, that doesn't work. There is also a power difference involved in discrimination, and here it starts: It's not possible to envision what some words might do unto others. Most of of the people within the Debian community are most probably white, able-bodied, cis (identifying with the gender assigned at birth), hetero, and male. Just to name a few most prominent categories. So even if we try to envision oneself in the place of the other person, we haven't experienced systematic discrimination like racial profiling, not able to enter a restaurant, being looked strange at whatever toilet we go to, have heads turned on us and people whispering when walking down the street hand-in-hand with our partners, or being cat called. And we might envision that being called "fag" isn't the nicest thing, people forget one thing: There is a huge power difference especially also in language.
How many discriminatory words can you come up for black people? Disabled people? Non-hetero people? Trans people? Women? And then take a step back ... and try to think about how many discriminatory words you can come up with for white, able-bodied, hetero, cis and male people. And then try to realize how even language plays into that power imbalance. Especially on the internet where the only thing you get from others is written language. So the one way to work with that is to actually listen to those facing discrimination and acknowledging that some words are off limit.
So next time you tell someone they are just a special snowflake, or that they should just swallow it down because that's the way things work ... think about this. And think about what you actually are transporting when you oppose to a political correct approach: When you consider political correctness something awful to strive for because it seemingly limits how you speak to and about others. Because honey, no, it doesn't. Anytime you belittle a political correct approach you are just showing one thing: That you are unwilling to be a safe space for the people around you, and simply don't care.
Oh, and one more thing: Free Software and Debian in specific always was political. Don't tell me that's news to you. Working on Free Software is an extremely strong political statement. It is to improve the world for everyone through making software available to everyone. And yes, that everyone includes non-white, non-cis, non-ablebodied, non-hetero and non-male people too, surprisingly to some it seems.
Enjoy, and happy new year!
P.S.: Part of this content is inspired by the German language book: Eine Frage der Moral from Anatol Stefanowitsch. If you understand German I urge you to read it. It gives a good insight.
People these days often do think about what worked well in the last year that they are proud of, what didn't work so well and what they plan to change the coming year. For me a fair amount of the resolutions were about my name. One of them was getting rid of my old name from the Debian—Project Participants page. Actually, I started with it on new year's eve already:
So far I've done a fair amount of my job. There are eight source package left to get tweaked. Those might be a bit more difficult and require more attention though. What I also did during those efforts: Convert all packages to source format 3.0 (quilt), and use a dh style debian/rules file. The latter enabled the packages to build reproducible too, which is also an added benefit. So this is a win situation on many levels.
One of the most prominent reasons why I didn't convert to a dh style debian/rules file yet was that I considered it making easy things easy and difficult things difficult. Finding out what to override and how to do that was something I was unable to figure out, and speaking with people didn't help me there neither. Only recently someone told me that there is dh binary --no-act to figure out what would be called, and then you just prefix it with override_ in debian/rules to get to where you want to go. This worked extremely well for me.
I'm personally still not a big fan of source format 3.0 (quilt) with respect to that it insists on patches to be applied and leaves them that way after building the source package, which makes it difficult to deal with when having upstream source in the VCS too, but I managed to find my way around so many things in the past that I can live with that. The benefit of not having to repack upstream source if it isn't in .gz form is a far bigger benefit.
So, I hope to stay productive and be able to get the remaining package also adjusted and fixed. Guess that's doable until the end of the month, and getting rid of all reproducible build bugreports against my packages along that lines. I will check those packages that carry my name already too after my old name is gone from the overview page.
I tried to start to write this blog entry like I usually do: Type along what goes through my mind and see where I'm heading. This won't work out right now for various reasons, mostly because there is so much going on that I don't have the time to finish that in a reasonable time and I want to publish this today still. So please excuse me for being way more brief than I usually am, and hopefully I'll find the time to expand some things when asked or come back to that later.
Part of the reason of me being short on time is different stuff going on in my private life which requires additional attention. A small part of this is also something that I hinted in a former blog entry: I switched my job in June. I really was looking forward to this. I made them aware of what the name Rhonda means to me and it's definitely extremely nice to be addressed with female pronouns at work. And also I'm back in a system administration job which means there is an interest overlap with my work on Debian, so a win-win situation on sooo many levels!
I'm at DebConf15 since almost two weeks now. On my way here I was complimented on my outfit by a security guard at the Vienna airport which surprised me but definitely made my day. I was wearing one of these baggy hippie pants (which was sent to me by a fine lady I met at MiniDebConf Bucharest) but pulled up the leg parts to the knees so it could be perceived as a skirt instead. Since I came here I was pretty busy with taking care of DCschedule bot adjustments (like, changing topic and twittering from @DebConf at the start of the talks), helping out with the video team when I noticed there was a lack of people (which is a hint for that you might want to help with the video team in the future too, it's important for remote people but also for yourself because you can't attend multiple sessions at the same time).
And I have to repeat myself, this is the place I feel home amongst my extended family, even though I it still is sometimes for me to get to speak up in certain groups. I though believe it's more an issue of certain individuals taking up a lot of space in discussions without giving (more shy) people in the round the space to also join in. I guess it might be the time that we need a session on dominant talking patterns for next year and how to work against them. I absolutely enjoyed such a session during last year's FemCamp in Vienna which set the tone for the rest of the conference, and it was simply great.
And then there was the DebConf Poetry Night. I'm kinda disappointed with the outcome this year. It wasn't able to attract as much people anticipated, which I to some degree account to me not making people aware of it well enough, overlapping with a really great band playing at the same time in competition, and even though the place where we did it sounded like a good idea at first, it didn't had enough light for someone to read something from a book (but that was solved through smartphone lights). I know that most people did enjoy it, so it was good to do it, but I'm still a fair bit disappointed with the outcome and will try to work on improving on that grounds for next year. :)
With all this going on there unfortunately wasn't as much time as I would have liked to spend with people I haven't seen for a long time, or new people I haven't met yet. Given that this year's DebConf had an height in attendees (526 being here at certain times during the two weeks, and just today someone new arrived too, so that doesn't even have to be the final number) it makes it a bit painful to have picked up so many tasks and thus lost some chances to socialize as much as I would have liked to.
So, if you are still here and have the feeling we should have talked more, please look for me. As Bdale pointed out correctly in the New to DebConf BoF (paraphrased): When you see us DebConf old timers speaking to someone else and you feel like you don't want to disturb, please do disturb and speak to us. I always enjoyed to get to know new people. This for me always is one of the important aspects of DebConf.
Also, I am very very happy to have received feedback from different people about both my tweets and my blog, thank you a lot of that. It is really motivating to keep going.
So, lets enjoy the last few hours of DebConf!
Another last side notice: While my old name in the Debian LDAP did manage to find some wrongly displayed names in the DebConf website, like for speakers, or volunteers, it was clear to me that having it exposed through SSO.debian.org isn't really something I appreciate. So I took the chance and spoke to Luca from the DSA team right here today, and ... got it fixed. I love it! Next step is getting my gpg key exchanged, RT ticket is coming up. :)
After a long time a new irssi upstream release hit the archive. While the most notable change in 0.8.16 was DNSSEC DANE support which is enabled (for linux, src:dnsval has issues to get compiled on kFreeBSD), the most visible change in 0.8.17 was addition of support for both 256 colors and truecolor. While the former can be used directly, for the later you have to explicitly switch the setting colors_ansi_24bit to on. A terminal support it is needed for that though. To test the 256 color support, your terminal has to support it, your TERM environment variable has to be properly set, and you can test it with the newly added /cubes alias. If you have an existing configuration, look at the Testing new Irssi wiki page which helps you get that alias amongst giving other useful tipps, too.
The package currently only lives in unstable, but once it did flow over to testing I will update it in wheezy-backports, too.
This year's debconf in portland will happen without me being there. As much as I would love to be at home again, I won't be able to afford it. As much as I'd liked to help to keep portland weird, a discussion led to the feeling that I'm not welcome there and along that lines made me miss the deadline for sponsorship request due to not being very motivated to push for it because of that. And without sponsorship I won't be able to afford it, given that I need to save up for my upcoming move.
This also means I won't be able to host the Poetry Night. I hope that someone will be picking up that ball and continue it. Personally I am more motivated than ever to start writing again, given that there is currently a Bus Bim Slam (Bus Tram Slam) happening over here in Vienna and I try to attend as much stations as possible, and there will be a Diary Slam during this year's FemCamp Vienna.
I'm indifferent on whether the Debconf Poetry Night should be recorded or not. On the one hand it would be great to see people performing, on the other hand it might shy away certain personal poems that one wouldn't want to have out in the wild. Whoever picks it up, think about that part.
I wish everyone luck in Portland, and I'm looking forward to yet another great job by the video team so I can follow a few talks from at home. It sort of breaks my heart to not be able to hug you lot this year, and I wish you a great conference. We'll meet again next year in Heidelberg!
Dear users and supporters of the backports service!
The Backports Team is pleased to announce the next important step on getting backports more integrated. People who are reading debian-infrastructure-announce will have seen that there was an archive maintenance last weekend: starting with wheezy-backports the packages will be accessible from the regular pool instead of a separate one, and all backports uploads will be processed through the regular upload queue (including those for squeeze-backports and squeeze-backports-sloppy).
For Users
What exactly does that mean for you? For users of wheezy, the sources.list entry will be different, a simple substitute of squeeze for wheezy won't work. The new format is:
deb http://ftp.debian.org/debian/ wheezy-backports main
So it is debian instead of debian-backports, and offered through the regular mirror network. Feel invited to check your regular mirror if it carries backports and pull from there.
For Contributers
What does it mean for contributing developers? Uploads for backports are no longer to be pushed to backports-master but to ftp.upload.debian.org, like any other regular package. Also, given that the packages are served from the same archive install there is no need to include the original tarball in the upload any longer because the archive knows it (Squeeze and beyond).
Also, given that the upload goes to the same upload queue, there is only one keyring used anymore, so no more pain with expired or replaced keys. We though still keep the rule of adding your UID to an ACL list (this also includes DM additions). This is mostly only to give us the chance to remind you that uploads to backports are directly available for installation onto stable systems and you thus should take special care there. We carefully tried to take over the old ACLs, in case you can't upload anymore, please tell us so we can look into the issue.
I've mentioned wheezy-backports (and squeeze-backports-sloppy) a few times here already, and you might wonder when it will be available. Technically, it is available from now on. Practically, while you could already upload to it, the set up of the buildd network is more painful than expected, so please allow the Buildd Team some days for setting them up.
The upload rules for wheezy-backports are the same: packages that are in the next suite are accepted. Given that Jessie isn't created yet, we want you to think about whether the package you want to upload will go into Jessie final, and that you are taking a closer look once Jessie is created and the package entered there about the upgradeability. For the time until the suite is available, you can see this as relaxed upload rule.
The same goes for squeeze-backports-sloppy: packages from two suites after Squeeze are acceptable, which turns it into the same relaxed rule as wheezy-backports above. Please also keep in mind that uploads to squeeze-backports-sloppy usually should be accompanied by uploads to wheezy-backports so people are able to upgrade from squeeze-backports-sloppy to wheezy with wheezy-backports.
Thanks
Finally, we want to thank the FTP-Master Team for their fine work on making this happen.
The documentation on backports-master has been updated, and in case of any doubt or question, feel free to ask them on either the debian-backports mailinglist, or in case of sensitive topics ask us directly.
We had in total fourteen participants. The number of release-critical bugreports touched and processed is not clear, but over 100 bugreports were looked at and either got comments added for clearification, maintainer pinged, unblock requests filed or already filed ones noted down, or NMUed. Given that we are in freeze since a while now and many easy bugreports already squashed by those who aim for a daily fix, I consider this impressive.
There is also the point that we managed to get some people involved that didn't consider themself techy enough to be of help. On the contrary, they were a great help on checking these bugreports with analyzing the discussions in some lengthy bugreports and upstream bug trackers, or trying to reproduce some issues. I can just hope that the weekend left an impression deep enough to keep them in the boat.
All in all, I'm quite pleased of the outcome, especially in the light of severalotherevents catching the interest of potential participants which were going on at the same weekend. Thanks to all the people that stumbled by, and I am looking forward to maybe having another BSP at some point, but then I hope to not clash with so many other events. Thanks!
Wheezy is coming closer to the release, there though are still way too many release critical bugreports outstanding for it. Squeeze has already been released, but it has collected even more release critical bugreports than wheezy since. To be able to reduce these amounts I will be at the Linuxhotel in Essen at the weekend from 23rd to 25th of November, and it would be a great pleasure if I could convince you to join me in this effort.
As readers of my blog might assume, my main aim will be those RC bugs affecting squeeze and I would be happy if some people interested to work on those could join me, I plan to give a quick quick explanation about the version tracking of the BTS and why we should care about stable too, but the event will definitely not be limited to squeeze RC bugs. Also, it will be a good chance to improve your key stats for the web of trust in case your GnuPG key hasn't got enough signatures yet or you want to transition to a stronger one.
Please read the Community page of the Linuxhotel for what they offer for accommodation in case you want to use their lodging. Personally I'll go for the two-bed room with breakfast option, but you are of course free to bring your own sleeping bag and mat if you want to cut short on the expenses.
In case of any questions, feel free to ask me right ahead. It would be great if we could help both our stable release and the next stable release during the weekend, and if you could join in! Please add yourself to the wiki page about the BSP.
This is the third summary of my squeeze RC bug squashing. If you take a look at the bug graph you will notice that the blue line went up a bit over a two week's period. I would like to claim that confirming the samhain RC bug 618728 did cost me the time (I actually gave it the time to finish), but the real reason was that I was looking at other stuff. I came back with a vengeance though, so here is the list of the bugs squashed for squeeze since the last report:
This is the second entry in my series about squeeze release critical bug squashing. In response to my last blog post it was asked whether this is proper release critical bug squashing. Indeed there haven't been any patches or upload involved in this, only BTS handling, but this doesn't mean that these bugs weren't considered to be affecting squeeze. You can see this effort currently as weeding out the "wrong" bugs so that the list gets more useful and actually be able to ask maintainers to address the real issues.
You can at least see in this graph that the blue line is going down constantly since the year change instead of rising up like before. And I hope I will be able to keep it below the green line for a while still. Also thanks to the release-team and ftpmasters that it was possible to keep the massbugs about waf binary blob not being preferred source for modification out of affecting squeeze and ignore it for the current stable release—the required changes for those would rather be a fair bit intrusive for a stable update.
I am glad that I managed to keep it up and even have a nice margin in case I can't put any effort into it some day but still have more bugs squashed than days there are in the year so far. Currently I am at 60 bugs in 39 days. This gives a warm feeling. :)
The following announce is lazily copied from Paul Wise's announce. There is only one thing I like to add: the screenshots that are submitted and collected on screenshots.debian.net are visible on the packages websites (both Debian and Ubuntu) and are also used by the software-center package, so they help people to get a first impression of the package they might want to install.
Have you ever wondered how to start getting involved in Debian/Ubuntu? Do you enjoy discovering new games and playing them? You might want to come to the games screenshot party! We hope that the party will be a fun, easy, low-commitment way to get involved.
The Debian/Ubuntu Games Team is organizing a half-day screenshotsparty on the weekend of 25th-26th February for creating screenshots for all the games that are available in Debian/Ubuntu.
If you are interested in attending, please add your availability to the poll linked from the announcement so that we can get some idea of attendance and when is a good time for the people who are interested.
Look forward to lots of game playing, screenshots and merry time, hope to see you all there!
As sort of new year's resolution I started picking up the habit to work on release critical bugreports for squeeze again. The number is way to high to be healthy, but at least it is (still) below the amount of release critical bugreports for unstable.
It will be an uneven fight because it seems that there are quite some people working on weeding out release critical bugreports in unstable, but those who are interested in weeding out releasing critical bugreports in stable seems to be limited, even though it is one of our supported releases and thus should receive quite some attention, at least by the corresponding package maintainers themself.
Another month, another Games Team IRC Meeting happening. This time it was decided to have it again on Sunday, the time was set to 10 am UTC. To find out the time in your localtime, issue date -d '2011-06-26 10:00 UTC' in your shell. The agenda can be seen as always in the wiki.
If the time or agenda doesn't fit your ideas, feel free to join our mailinglist to be informed about the discussion of agenda and time for the next meeting and raise your voice at that time. Please notice that the agenda isn't final yet, you can still drop your ideas for that.
Enjoy, and join if you care about improving games packaging in Debian and influence future development!
As Evgeni Golov already blogged, there is going to be the next round of a IRC meeting of the Debian/Ubuntu Games Team on the upcoming Saturday. This time it will be held at April 30th at 12:00 UTC in #debian-games on irc.oftc.net, so if you are interested in bringing the Games Team up to pace again, want to join and wonder how you could help, please attend. The agenda contains a fair amount of leftovers from the first meeting, please see Meeting Page about it.
If you weren't online last Friday you probably have missed the big news announcement on the variouscommunitydistributionwebsites. The main pages of them got replaced by a placeholder announcing the birth of The Canterbury Project. People started to wonder whether it is an April fool's prank or for real. This blog post is meant to shine a bit more light on it and address one comment received about it.
If you go to the news item on the Debian site you'll get your answer about that it indeed was an April fool's prank. The idea for doing something in coordination with other distributions came to me when I thought about last year's (or was it already two year's ago?) prank that the various web cartoon sites pulled: they replaced their main page with the page of another cartoonist. My original idea was actually along that lines. So I started to dig up website contacts from different distributions, I was aiming at the big names in the community distribution sector.
Given that my time is pretty limited these days with renovating the house we plan to live in soonish I knew I had to let in others in within Debian. I though didn't want to involve too many people, for several reasons: it should be a surprise to as many as possible, but more importantly, I didn't want to shy away other distributions by an overwhelming Debian involvement. That's also part of the reason why I didn't contact many Debian based distributions.
So first contacts where made, a dedicated IRC channel used for coordination, and people involved joined in. Then the thing happened which the Free Software community is so well known for: additional ideas came in, two people independently addressed me whether it wouldn't be better that instead of a circle replacement of the frontpage, why not display the same page on all of them. And one of them added that a corresponding news item might make sense.
So there we were, having to think about text to put into two things: the news item and the replacement page itself. At this stage Alexander threw in a project name with a background that was adopted. Francesca started with an idea for the news item, I started to put quotes in and asked for ones from the other involved people that fit their distribution well. Klaas came up with a template for the replacement page that we tweaked. Fortunately we ended up being five distributions and the colors of the banner did match the distribution ones rather well (except for one, we had to tweak the color of one banner).
The Credits
We were all set, and actually everything went fine. And it definitely caught the attention. This blog post goes out in thanks to the following people:
For Arch Linux: Pierre Schmitz and Dieter Plaetinck—thanks for joining in on such a short notice!
For Gentoo: Robin H. Johnson—thanks for the best quote for the news item!
For Grml: Michael Prokop—thanks for the great live CD and your input!
For openSUSE: Thomas Schmidt and Klass Freitag—thanks for the perfect website theme and the best mocked up news item!
... and most of all, to the to be left unnamed person from the distribution that didn't join in in the end: a lot of thanks has to go in that direction because of the invaluable input. The actual idea about the additional news item is to be accounted to that person, and the Canterbury logo was tweaked there too.
I hopefully haven't forgotten anyone. There surely were some more people involved in the other distributions, and I guess the named people weren't aware of all the ones involved inside Debian. Feel free to drop missing names in the comments.
Addressing Feedback
Finally, let me address one concern raised: someone claimed that the real joke with this prank was that we would consider collaboration to be a joke. Actually, the total opposite is the case here. That it was possible to pull it off should be proof enough that Collaboration Across Borders actually is possible. And the background information put into the news section of the replacement site is real. Also, my personal quote in the news item was meant dead honest. I do believe that DEX has a limited point of view and only tackles part of the problem.
Unfortunately, for such efforts to really come to life it takes people with a really long breath and dedication to it. Efforts like the VCS-PKG and the Freedesktop Games effort are more or less stalled. Even though a lot of people do believe in stronger collaboration to be a good thing, the basis is not working out too well. I'm in the fortunate position that for some of the packages I maintain there is exchange between packagers from different distributions to avoid common troubles. If it can't be done in the big it should at least be tried in the small.
I want to specifically highlight again one part of the updates in the replacement page: the CrossDistro track at this year's FOSDEM. This one was more than fruitful, on several levels. From what I've heard a lot of discussion happened besides the talks too, and connections got established. It doesn't sound unlikely like this might be done again next year.
So again, thanks for enjoying this April fool's prank, thanks to everyone who helped to deliver it, and especially a lot of thanks to the people who this might have got thinking of possibilities to improve on the collaboration front!
Yesterday I was hinted towards lxc when I wondered what happened to openvz in unstable (which unfortunately isn't documented at all in the kernel changelogs, but that's a different story). So I started off taking a look. From a bit of experimenting around with it I consider it something that I want to play more with, and I want to share the problems I stumbled upon with you so that you don't have to figure them out on your own.
First of all, LXC uses the cgroup kernel facility for resource management. The according file system isn't mounted by default, and LXC doesn't care for where it is mounted, it just needs to be. It seems like /sys/fs/cgroup seems to be the proper place (see 601757), so add the line cgroup /sys/fs/cgroup cgroup defaults 0 0 to your /etc/fstab file and sudo mount cgroup it.
Next, it seems like bridging is the defacto standard for networking with lxc, but given that I want to use it on my notebook while being mobile I can't bind the bridge to any specific interface. To make this happen, one needs the bridge-utils package installed, and secondly, this is the path that I chose. I've added to /etc/network/interfaces this snippet:
This will bring up the bridge and act as gateway. For the running system, call sudo ifup br0. To make the host universally being able to work as gateway, of course ip_forward needs to be enabled. For this I added the line net.ipv4.ip_forward=1 to /etc/sysctl.d/local.conf (and for the running system, echo 1 into /proc/sys/net/ipv4/ip_forward).
As I am using ferm for configuring the firewall on my notebook I have to add some parts into its configuration. This is the raw part that needs to get added, mix it into your existing configuration:
table filter {
chain INPUT {
# allow DNS queries from LXContainers
proto (udp tcp) dport domain source 10.80.80.0/24 ACCEPT;
}
chain FORWARD {
# allow LXContainers into the net
source 10.80.80.0/24 ACCEPT;
}
}
table nat {
chain POSTROUTING {
# NAT LXContainers
source 10.80.80.0/24 MASQUERADE;
}
}
For DNS I installed dnsmasq so that I won't have to touch the /etc/resolv.conf inside the containers whenever I switch networks.
So far for the host part, now to the actual containers. There is the /usr/lib/lxc/templates/lxc-debian helper script which uses debootstrap to create you a lenny chroot—at least in the squeeze package this is hardwired, likewise with using cdn.debian.net. Copy the script and edit it to your likes if you feel like it. From what I understood it expects you to store the containers below /var/lib/lxc, I haven't yet tested for different places. So this was my commandline for that: sudo /usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/vm0
A while later you'll end up below that directory with two entries: The config file and the rootfs subdirectory which is actually the bootstrapped distribution part.
Now comes the configuration of the container. Open the config file with your favorite editor and add the following lines to the end:
The network.name part is commented out, it defaults to that name internally; you though can change it to whatever you prefer. Caution, even though this is the documented approach, it does not work for Debian containers. It will always try to get its IP address through dhcp, lxc.network.ipv4 has no meaning for us. We need to change inside the rootfs the file etc/network/interfaces to read like this instead:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.80.80.80
netmask 255.255.255.0
gateway 10.80.80.1
I suggest to keep the config and the interfaces file aligned with respect to the ipv4 setting so if this gets fixed upstream you won't stumble into any surprises. Also like mentioned before, we need to change the nameserver entries inside the rootfs file etc/resolv.conf to read nameserver 10.80.80.1.
Now it's time to start it up and log in! sudo lxc-start -n vm0 -d will start the container in the background, and sudo lxc-console -n vm0 will give you the login to the container. The default password for the root user is root, obviously you want to change that before you install any networking services into the container like ssh-server. In case you want to quit from that console notice the message upon starting it, it's bound to <Ctrl+a q>.
One more issue that I had: The default route wasn't set. I had to manually call ip r a default via 10.80.80.1 dev eth0 to be able to use the network inside the container. It seems to be related to that netbase isn't installed by default. If you install it the default route will be set upon starting the container automatically.
This should get you started, there is of course more to explore and experiment with. Actually it is also suggested to create a tarball from your vm0 after you did the basic setup and installed the basic components you want to have around so you won't have to bootstrap over and over again. Do this after you have shut down the container, either through a halt from a container shell or through sudo lxc-stop -n vm0. The tarball can then get extracted to a different directory and just needs minor tweaks in the config and rootfs/etc/network/interfaces file to not create any clash with other containers (lxc.rootfs, lxc.mount.entry, lxc.utsname, lxc.network.hwaddr and ipv4 address).
About limiting the containers, you can do it dynamically through the cgroup file system, and set it permanently through the config file. See man lxc.conf about these settings, amongst others.
Enjoy, use, experiment. With sudo lxc-checkconfig you will see what your kernel actually supports for your LXCs. You will most probably notice the missing for the memory controller, this is tracked in the Debian bug report 534964.
As Paul Wise already blogged, there is going to be a IRC meeting of the Debian/Ubuntu Games Team on the upcoming friday night. It will be held at 18th of March at 21:00 UTC in #debian-games on irc.oftc.net, so if you are interested in bringing the Games Team up to pace again, want to join and wonder how you could help, please attend. The agenda isn't final yet, the doodle poll about it is still open, if you want to put your preferences in.
Another week, though this one wasn't as fruitful as the last one. My excuse here is that I was overwhelmed with private stuff like acquiring a house and starting with cleaning it up so it can become a home.
This is the list for my second week of my stable RC bug squashing:
603846: Update LSB header for hal D-Bus activision, not relevant for squeeze.
604299: please use KDE 4 port, not relevant for squeeze.
608017: XLIB package is not available even after installation, only appears in relation with clisp 2.49.
I know three isn't much, and actually it doesn't impact the list of stable RC bugs not much, we are at 172 open RC bugs against squeeze now. I can only attribute it to that new bugs were filed since, because I am aware that I'm not the only one working on this front, I've been contacted by at least two other people in the last week that are investing some time into this, too.
Mostly for self-reference, the highest reported squeeze RC bugs in the list is 618295. This should help me to get a number of newly reported issues (ignoring severity-bump in lower bug numbers).
Alright, the stress of the release and its aftermath with respect to the New Website is getting lower. We even were explicitly mentioned for that during the introduction to the category Outstanding Contribution to Open Source/Linux/Free Software at this year's Linux New Media Awards.
Given that the Webmaster Team is much more energetic and lively these days I will shift a bit of my efforts to stable RC bug squashing again. I came to the conclusion that working on lenny RC bugs doesn't gain much of appreciation or real turnaround, and given that my time is limited I started to switch over to work on squeeze RC bugs. This is the list of bugs that I squashed last week (actually, marked them as invalid/not affecting squeeze):
549054: Still uses gmime2.2, not relevant for squeeze.
549056: Still uses gmime2.2, not relevant for squeeze.
549057: Still uses gmime2.2, not relevant for squeeze.
549058: Still uses gmime2.2, not relevant for squeeze.
554310: FTBFS with binutils-gold, not relevant for squeeze.
554557 FTBFS: undefined reference to symbol 'gzclose', not failing in squeeze.
596569: Depends on xview, not relevant for squeeze.
I hope to be able to keep up that pace for a few weeks (currently there are 168 RC bugs in squeeze listed), and hopefully being able to motivate others to also support our stable release instead of only working on unstable.
5 Reasons why Debian Unstable is Not for End-Users
Debian unstable is not conceived as a product for end-users, and for very good reasons. There seems to be some misunderstanding and people trying to push end-users to use unstable. This blog post tries to address the claims raised and put them into proper light.
1. It contains mainly stable versions of the software
The critical part here is the term mainly. Yes, developers are advised to only upload packages to unstable that they deem to be suitable for the next stable release. This is no hard requirement though and no one actually playing a gate-keeper enforcing this recommendation. Also, there is a fine amount of packages that follow either VCS snapshots or development branches, and only time can tell how stable those releases actually are. That's actually why there is a delay of several days before a package can transition over to testing.
2. It doesn't break badly every other day
That's right—but if you look at it, it also means that it does break badly eventually. And if you don't know how to move on from there, including knowing the location of maintainer scripts and how to edit them in those cases, or even resort to a rescue system, you are in troubles.
3. It's the basis of other distributions
That's right in itself too, but it doesn't address the fact that those other distributions do put a lot of effort into quality assurance to work around the most nasty and annoying bugs that do affect unstable every other day.
4. It's not inherently less secure than Stable or Testing
It's not inherently more secure than stable or testing either. And this is also ignoring the fact that some security bugs don't even get into stable or testing, they only affect unstable and have to get addressed just there.
5. I use it on my main computer
This is the reason that you should ignore as most. People using unstable are often enough deeply involved into Debian maintenance, know how to write maintainer scripts, know where they are located in case of troubles, know how to use a rescue system in case of bootloader or kernel troubles. Just think about whether you would consider yourself to be at the same knowledge level than the person who wrote the blog article you read that used this as a convincing argument.
Conclusion: Stories always have several truths attached to them. If you feel adventurous, like to understand what's going on and have a tendency for digging into things that go wrong, you most probably are using unstable already anyway and are reporting bugs that you find along your way. If you on the other hand rather just want to use your computer and don't want to work around (smaller) bugs every other day, you rather should stick with the release that is actually provided as purpose to suit the needs of end-users: stable.
Like you most likely know, I've been at the openSUSE Conference last week. I've been representing Debian through a talk about Debian - The Project and its Resources, covering services and resources that are usable and useful for other distributions too. The invitation to submit talks were sent to various projects and distributions because of the set topic on Collaboration across Borders for the conference. My impression was that very few distributions have followed the invitation, I am only aware of some Fedora people that have attended. Vincent Untz from GNOME gave a combined keynote with Cornelius Schumacher from KDE.
The abstract of my talk and the slides are available from the conference website. The talk was well received and interested people also asked about some of the services like how our buildd network works, or whether the screenshots service has support for localized images too, or if it would be expandable for more general usage of non-Debian based distributions.
One topic raised was with respect to the whohas tool: A mapping layer/tool/database for package names. We divert from upstream naming schemes for consistency reasons, like with our library, Perl and Python naming schemes. Other distributions have similar approaches but a different naming scheme. To make inter-distribution tools really useful it would require to have some layer that is able to map the package name from one distribution to another one. One idea for it that was thrown in was to use upstream homepage, but not all packages do have proper homepages, some only live in some git repository, others would either like to link to sourceforge's project page instead of the project's homepage, and other tricky issues. Something unique is clearly called for here and needed to get stored in the package's metadata.
Apart from my talk and the occasional mentioning of openSUSE is on my desktop, but I run Debian on my server I noticed that the beverage of openSUSE is their own beer. Taste is a tough topic, personally I rather prefer our Debian wine. And I missed the chance to seduce them into playing Mao, I forgot to bring playing cards along. I hope to get a second chance at anoter event.
Within the next few days there will be the openSUSE conference held in Nuremberg/Germany. The topic of the conference was set to Collaboration Across Borders and along that theme they invited other distributions to submit talks. Given my involvement with the Derivatives Frontdeskzack asked me whether I'd like to submit a talk proposal. I usually have a hard time to refuse such questions this will actually happen.
My talk will be in the Distributions Track on Thursday afternoon, the topic is Debian—The Project and its Resources. The resources that I will cover are those that can be very useful to other distributions too, and last Thursday I tested the talk at our local Debienna Meeting, gathered further ideas and feedback to cover in the talk. Thanks to you, guys!
Unfortunately contrary to what we are used to in Debian (extraordinary thanks to the Video Team!!!) there will be no streaming or recording of the talks from what I was told, so you have either to hurry to be there, or be satisfied with the slides I'll put up after the talk. It's the best I can offer.
I wrote the following as a foreword for the great German book Open Source Projektmanagement that Michael Prokop wrote. Unfortunately the foreword didn't manage it in time into the book because of various circumstances. As I'm not a person to throw away already written material, here is it for your reading pleasure. Maybe it makes you consider obtaining a copy of the German language book for yourself!
The Whole is more than the Sum of the Parts
When I first met Mika at a Linux conference some years ago I quickly noticed that he had potential. The way he asked questions and tackled issues did impress me. We did meet again at various events, joined forces in various projects and knew that the result would be good.
Back in the year 2004 the only real live CD was Knoppix. It always was too sluggish for me because I never really liked KDE and also OpenOffice.org was too bloated for me. I was working since a year at an Internet provider, felt comfortable in the shell and was missing the tools on Knoppix which I used daily.
Often enough the frustration with the status quo starts the best projects. And so I had the idea spinning around to start a sysadmin live CD. There was just one problem here: Exactly at the same time Mika had already started such a project. And I knew one thing: it would had been a lost race to compete with him in creating the better live CD. So I joined his team and helped with the best of my knowledge. The name choice alone showed that he was the right person for the job: Grml—an expression of the frustration that even he felt which spoke directly to the heart of so many.
But it wasn't just the chosen name that showed that Mika was the right person for the job of the project leader. It's always the sum of the parts, no matter how minor they might look. He quickly managed a first release and in light of that also created an event which was fitting for the release of the first version: the OS04—an Open Source event which managed to get Jon Maddog Hall as keynote speaker.
Mika managed through his welcoming way to lure more people into helping out. The team grew over the years, further regular releases increased the fan base, not only through the creative release names—which are surely one of the parts that helped create the success. He always was open to suggestions for new tools that helped to extend the project.
The lived openness did lead among other things to the case that other live CDs started to use the grml build system. JUXlala 2.0 (the system for preschool kids) is just one example.
Why do I write primarily about Grml, one could get subliminal advertising probably cheaper? I do it because Grml is an extremely good example of the experience revealed in this book. And even though every project is different, it is still exactly the sum of the parts that leads to the success of a project. And exactly these parts are covered in this book—and can be considered for the project at hand and get implemented accordingly.
People start to wonder why the timeouts for the passwords in sudo seem to be so short recently in squeeze. The reason is a change in the defaults that causes it. The following option changed its default:
tty_tickets
If set, users must authenticate on a per-tty basis. Normally, sudo uses a directory in the ticket dir with the same name as the user running it. With this flag enabled, sudo will use a file named for the tty the user is logged in on in that directory. This flag is on by default.
To change it back you can add this line into your sudoers file:
Defaults !tty_tickets
Please be aware that the change in default is done because of security considerations. You might not always have all the ttys you are logged in directly visible and others might be able to access them (like, sudo on a remote SSH session). Use with caution, you though might consider disabling it on local systems with no remote users.
Hope that helps! Actually this blog post was triggered by a question on ask.debian.net, a new service in the Debian eco system.
The Backports Team is pleased to announce the availability of a new suite on backports: lenny-backports-sloppy. Please read carefully before considering using or uploading to it what this entails.
The Background
You might want to ask: What's that? Let me explain it. During the etch release discussions popped up on the backports list with two clashing groups:
One that expected to always be able to upgrade from sarge + sarge-backports to etch without backports,
others that wanted new versions of packages flowing in even after the release and were happy to upgrade from sarge + sarge-backports to etch + etch-backports.
The standing at that time was to accept packages that were in testing after the release, which wasn't etch anymore but lenny.
The same discussion started again before the lenny release, and given that we are facing the upcoming squeeze release we started internally to discuss how to noise down these long and tedious discussions, because both groups of people had valid opinions that shouldn't get ignored. So this is where the idea for lenny-backports-sloppy comes from.
The Change
lenny-backports-sloppy will please the group that is happy to upgrade from lenny + lenny-backports to squeeze + squeeze-backports. lenny-backports is meant only for packages from squeeze, even after the release. Technically that means it will get locked down for uploads after the release of squeeze and require manual approval (for e.g. point release update versions, or security updates that happen during the squeeze release cycle), while lenny-backports-sloppy will accept packages from wheezy. Uploading to lenny-backports will have to get approved by the Debian Backports Team after the squeeze release, just like uploads to lenny are currently approved by the Release Team.
While lenny-backports-sloppy is created already and working we ask you to not upload packages there without prior discussion with the Backports Team. This is meant to ensure that the Uploader is aware about the expectations that come along with that: The package should have a good chance to get included in the next Debian release aka wheezy, and that the Uploader is willing to look after the package in the upcoming squeeze-backports suite after the release of squeeze to ensure upgradability.
We are also pleased to announce that the first upload to lenny-backports-sloppy already happened. From now on you will be able to install Postgresql 9.0 (which is not targeted at squeeze) from lenny-backports-sloppy.
How to use
If you want to use lenny-backports-sloppy you will have to add both lenny-backports and lenny-backports-sloppy to your sources.list. Backports from lenny-backports-sloppy may depend on packages in lenny-backports.
deb http://backports.debian.org/debian-backports lenny-backports main
deb http://backports.debian.org/debian-backports lenny-backports-sloppy main
About Backports
You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in.
Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. It is recommended to pick out single backports which fit your needs, and not to use all available backports.
Thanks for reading this far, and enjoy!
Rhonda in the name of the Backports Team
It is a while since we managed to get below the 1000 stable RC mark. Last weekend we managed the next mark, that is we are below 900 now! Obviously my effort during the RCBC did take us a fair step in that direction, but I don't want to take full credit for it.
The last bit that got us below the 900 happened through an event of last weekend: The current point release of lenny. Be aware that the BTS doesn't know about proposed-updates, so bugs closed through uploads to there only are seen when they hit the main pool—which is the reason for point releases. It were something around 25 RC bugs that were closed by that. I haven't checked who exactly is to thank here, but looking at the non-DSA packages one finds some perl packages and at least two font packages. Thanks to the corresponding teams for their help!
I plan to continue these efforts, so if you think it's a good idea you might want to flattr it. I think this quote sums up the motivation behind this pretty well:
<jwilk> Yay, only 900 bugs to fix and we can release lenny! Oh wait...
I started to give flattr a try, too. It is a social micropayment site and the similarity of its name to the verb flatter is on intention. It is meant to say thanks in small amounts month by month to "things" you like. One such thing I created is my blog—you can find the link to it below every entry. To be able to flattr someone one needs to create an account on the site and put money into their account. After that it's possible to follow the flattr button links. If you are reading my blog on my site and have JavaScript enabled you just have to click the flattr part of the image (not the number) to do so. If you are reading it through my feed or with JavaScript disabled you will have to click a second time on the flattr site to make the flattring happen.
Another thing I've created is Debian BTS: cleaning up. I use this link in my mails to the Debian BTS for my stable RC cleanup efforts, or general proper closing of bugs that aren't getting archived. Through the help of UDD I've created me helpful overview pages of bugs that need attention for this.
The third thing I've created is Package Maintenance. If you are a fan of one of the packages I maintain and want to thank me for taking proper care of it, feel free to also click this one. Please be aware that this shouldn't be seen as an Upstream appreciation—if one of the projects I package for Debian uses flattr themself then you should definitely (also) consider flattring them for their own.
About Upstream projects that use flattr: One of the packages I invest quite a lot of effort into started using flattr: wesnoth. They have put the flattr button on their entry page at wesnoth.org, here is the direct link to their first and general thing: The Battle for Wesnoth.
Please be reminded that the things you did flattr in a previous month can again be flattred the next month. This is especially true for general purpose things like what I am using currently. Others might create things for every single blog entry, or very specific tasks, to allow people to flattr them more often in a month and get a bigger share of the cake. So keep in mind which things are general ones and consider returning to them.
People often want to know what an application looks like before they install it. This is one of the reason why Christoph Haas started with the screenshots.debian.net service. People can upload screenshots for their favorite applications for others to take a look at.
Finally, as convenience feature, they are now added on packages.debian.org. When you click on the screenshot of a package you can see the list of all of the available ones.
In the case when no screenshot is available yet the page will show a placeholder image which gives you a convenience link to the screenshots page of the package where you can submit one for the benefit of all. Please make sure that you are following the guidelines for submissions, otherwise your upload might get rejected.
On a not totally unrelated topic, the packages.ubuntu.com site finally will also show you packages in maverick. It doesn't show screenshots yet—if you think adding support for screenshots in there would be a good thing too, please let me know!
Happy 17th Birthday, Debian! You kept me busy for the last 10 years and I am really looking forward to what the next 10 years might bring for our relationship.
Thanks also to all the people who also are able to keep calm and to the point when discussions turn to get heated. You are the ones who make work on Debian enjoyable.
Also a lot of thanks to all the people that understand the power of positive encouragement like what is currently flowing in through the thank.debian.net website.
Likewise much thanks to the ever growing number of distributions that are based on Debian, because doing that is a very special kind of appreciation of our work.
This blog post is actually a response to a talk that was given at the debconf last week. It was marga's talk about Making Debian Rule, again. Now that the beta versions of the talks are available for download I'm able to proper quote what I want to respond to: Is there a reason why we haven't yet updated the website?, perhaps someone can answer.
I feel the need to respond to this as I am the main person driving that effort. Unfortunately the question was asked in a talk with no-one involved in that work around instead of addressing those people directly, and the question wasn't brought to my attention before the talk so that I could have provided an answer to offer in the presentation already. Also, as disclaimer, this is my personal story for it and doesn't need to get shared by the other people involved. I hope it can be seen as an answer anyway.
As a little of background, Kalle's proposal went a long path before even I found out about it. I was simply in awe in several ways about it because it wasn't just a great mockup of the page (which it actually is, IMHO) but was accompanied by thoughts about not only the main site but also about several sub sites. Also, it was accompanied by patches, so it was seemingly ready to get deployed right ahead.
I started working on it, got accused of being discouraging while doing that, got told that it would require a proper vote for a decision and can't happen just as, but those are just the Debian way of communication. I nevertheless did set up several test sites for some over the time to play with it. Some did work out better (like the git one, though this one came last and Kalle improved the CSS over time a fair bit), some weren't ready yet (like wiki, missing e.g. the coloring for the version diff, or the packages one where the separation between the different sections isn't that visible yet). Time passed, other things demanded their attention too.
Like the thing where our system administrators did send me a request along about a new www-master server that needs to get set up from scratch. Given that the documentation about the required packages for the website was lacking a fair bit (to say the least) it did require a lot of attention, especially when doing things from scratch the wish to document the dependencies properly is just natural. There are still some issues with that as can e.g. be seen on this page in the empty table at the bottom. The same issue also appears on my testsite for the new design.
The last part though is currently the biggest blocking issue for both efforts. There is no way to move forward with either without having that addressed. Simon Paillard did a great job on helping the move along so far, keeping the thread about the server move requirements that I started on the debian-www mailinglist updated with information about what's still pending. Unfortunately Kalle, Simon and me are also facing some private time constraints (amongst other duties that require attention) which weren't helping to move forward at a bigger pace. Unfortunately not very many people actually has shown interest in helping out neither, after all it's easier to go and ask questions about why it's not done yet to the completely wrong audience.
My plan is to switch many sites at the same time instead of one after the other simply for the effect but also for less distraction for our users, including less people repeatedly pestering about when this or that site gets done, too. At least we need a final discussion on what should go into the header links and what should be at the bottom before a switch can be made anyway. And for some there is still the opinion that such a switch is nothing that we are rightfully allowed to decide without a vote, so that's also part of the reason to not just deploy it.
I hope this answers the question to some extend—and like said, if only I would had been addressed about this before the talk was given an answer to it would had been ready for presentation right ahead instead of having a pretty terse statement getting relayed through IRC (thanks, Yoe!) because I was fortunate enough to be around and watching the talk at that time. Feel free to discuss it further or offer your help on debian-www, especially if you are familiar with working on CSS files.
You might remember that I started to work on closing RC bugs for stable. This effort hasn't died off so I joined the RC Bug Squashing Contest that was going on during the Debian conference (which I was unable to attend). The rules did permit it, even though I was aware that it can't (and shouldn't) be compared to the unstable/testing squashers and thus it was split of into its own Special category.
There still seems to be a lot of confusion on how our BTS works, especially with respect to version tracking. I was even accused of falsely claiming bug closing because the bug has been closed by someone else already. This wasn't the case, otherwise the bugs would had been archived a long time ago already[1]—given that I had expected that person to know how bug archival works and also given the sheer amount of bugs that I simply had closed for stable, I guess it is needed to shine a light upon why some bugs won't get archived as expected.
If you followed my IRC talk on BTS usage last month you might already have an idea of what's going on. There might be several different reasons why bugs aren't marked for archival yet. I'll try to explain them as I understand it (given that I neither have taken a look at the debbugs code nor am involved with its development) through my working on bugs over the last 10 years.
Usually bugs are marked for archival when they are not affecting testing or unstable. That means, for a bug filed against a version that is only in unstable and closed in unstable, an immediate archival process is started (actually, it's not that immediate: It requires the package to be in sync on all architectures it's available for, too); otherwise the fix has to enter testing before bugs are considered for archival.
Sometimes the bug is still considered affecting unstable though, even when the fixing package version already moved over to testing. This is the case when the hurd-i386 package is outdated in unstable and can be checked in the unstable overview of the package on packages.debian.org at the end of the page, it will have red entries next to the green ones (you can ignore red entries for debports architectures, though!). You have to file an arch specific removal request for those bugs to get them archived.
For packages in experimental it's quite the similar situation, because that packages from experimental don't transition anywhere, so those will stay unarchived for the time being if they also affect unstable.
So what can be the reason when the fix is already available in testing and unstable but the bug still doesn't get archived? Those cases mean that the bug is considered as affecting stable and has to get addressed there, too. Bugs that are considered for that are of a release-critical severity, bugs with lower severity aren't considered for stable because they are unlikely to get fixed in stable and thus get archived. So what can we do about them?
Do they actually really affect stable? Working on those is what I did over the last months. There are often enough bugs filed for library transition issues, FTBFS for toolchain changes, or other things that aren't applicable for stable. Those are easy to close in stable:
If the version information got lost (through reassigning or similar), the only thing needed is to re-add the found versions, given that it is a higher one than the one in stable.
If the version information is proper (because it had still the same version in unstable at the time of the reporting) tagging them with + squeeze sid will tell the BTS to consider them only for those releases, so not thinking it affects lenny, too.
Some do affect stable but still aren't severe enough to warrant an update in stable (like for documentation corrections in debian/copyright or similar). If you found one of those please talk to the release-team about getting them tagged lenny-ignore, don't do that yourself because that tag is meant to be set by the release-team themself only!
If they actually affect stable (like security issues that though are considered to be too minor by the security team to warrant a DSA, or other severe usability issues), please try to backport the relevant fix, propose a diff to the release-team on their mailinglist and have it uploaded to lenny-proposed-updates to be fixed in the next point release.
I hope this will get others also interested to fix stuff for stable. Actually when I see something that potential falls into the last group I ping the maintainers of those packages to let them know about having them fixed. Some of you might already have received such a ping and I am thankful for those that received them well and actually already fixed some of those, too. Thanks for making stable a better place!
Coming back to the RCBC, it was an interesting small competition (if only in my brain) between myself and the testing/unstable RC squashers going on. It would had been nice to get at least as many bugs in stable addressed as in testing/unstable because the amount is still a lot higher, but I can still be happy about the things done. And it is good to know that not everything seems to think that it's wasted effort to work on getting the RC count lower for stable, too (like I also was told about my effort). So thanks from that point of view!
[1] There are currently 2688 bugs still unarchived that were closed last year already! This UDD query helps you: select count(*) from bugs where status = 'done' and last_modified <= '2009-12-31';
Debian always was known for its communication "style". There were even shirts sold in memory of Espy Klecker with a quote he is known for: Morons. I'm surrounded by morons. Yes, I bought me one of those shirts too in the early days. And there were the talks that promoted Debian as a place to have Goodflamewar training. And people considered that to be the fun part.
After some years it got tiring. It got stressful. It got annoying. Bad feelings popped up, stirred you into the next flamewar, and it went down the gutter from there. It was almost becoming impossible to not be the target of a flamewar when one was doing more than just basic maintenance. Snide and extreme terse responses became the standard.
In the end people are starting to give up and leave. The Ugly thing about this is that human resources are crucial. They aren't endless and can't be replaced as easily as broken hardware, especially when capable people or when people leave who invested an enormous amount of their spare time and effort. And given that a fair amount of people do put their heart into Debian, it feels like a small suicide to them and the public thinking about leaving is meant as a call for help which wasn't and isn't given.
The solution to this death swirl? I'm not sure. When one looks over the edge of the plate and ignores for a moment all the bad feelings they one might have built up against Ubuntu because of their success and possibility to find new contributors on a regular basis one is able to find a much friendlier and productive environment there. This might be attributed to the Code of Conduct about which I wrote about last year already and which is an extremely well intended and useful document (the point I raised in there is already solved for a while, so I became a MOTU). And even if it might be hard to follow it at times, Mark Shuttleworth reminds and encourages its contributors to stick to these principles even in tough times.
The result? When following the planets, one finds on Planet Ubuntu a very good rate of blog posts on things that had been done, compared to the good rate of blog posts of rants on Planet Debian. And even though people regularly complain about the communication style within Debian, the answers of this year's DPL candidates to the question about a code of conduct for Debian were rather rather disappointing. So it is just well too understandable that people go the path that hurts themself, take a cut and leave the project behind in its mess.
For myself? I'm not too far from that point on a regular basis, and I can understand those who did the final step only too well. Regular abuse, especially when doing stuff that others neglect on a regular basis but needs to be done anyway, being belittled on that grounds and not being taken serious and getting disrespectful responses isn't improving the situation. It happens to way too many people, and the only thing that still keeps me on tracks is that I do not want to give in yet, that I don't think that it would improve Debian to leave the grounds to various destructive people.
We ain't dead. A long time has passed since I last wrote on this topic, and much happened—unfortunately (for this effort) in other areas.
This doesn't mean that this effort is being abandoned. So here is the next big step: A gitweb theme using Kalle's proposal. I enabled it on my own gitweb installation so that people can see it live and test it. Feel free to clone it from there, too.
Some people still ask me from time to time when I'll upload Battle for Wesnoth 1.8. My usual answer is that it's there already since before the official announce went out in the wesnoth-1.8 package.
The longer answer which also answers Why the name change? goes like this: People asked for a way to be able to install different branches side-by-side so that they can keep the old stable branch around for finishing started campaigns there while still being able to play with their friends multiplayer games using the new stable branch. Also people using the development version wanted to not having to get rid of the stable version just to use the development branch.
So there it is! Enjoy! There though is still something missing though, and that's why the question where the 1.8 version of Wesnoth is still pops up: There is no transitional/meta package yet. This requires a bit more work including adding alternative handling (so one can still run wesnoth and not have to use the versioned wesnoth-1.8 binary name) and for that some dpkg-divert magic about the historical unversioned wesnoth packages.
Given that my release is requesting quite some support overhead I can't tell yet when these things will be done, but a similarly related support contract will run out by the end of the month so potential I'll be able to find some time next month to finish this for good. If you want to have it done earlier or feel like helping out, feel free to send in patches after talking with me about the fineprints and potential approaches. Thanks in advance!
You are missing the point - debian/source/format allows you to make it explicit that the source format is 1.0, if you want to stick with that.
You are missing the point - the planned switch of the default format isn't considered a good approach by quite some people. If something new gets introduced, switching to it should be done in wake manner. Other tools do that too, so why can't a central package as dpkg use that approach? I especially want to mention that a point release update for stable was required to get it working in stable like it should.
A while ago Ganneff wondered weather it would be possible to make the matcher extension of rxvt-unicode also pick up something like #12345 and turn it into a link into the BTS.
It isn't—or rather, it wasn't. The idea got stuck in my head and invested some time to make it happen. Here is the quick'n'dirty diff to make it happen:
--- /usr/lib/urxvt/perl/matcher.distrib 2009-11-30 06:44:07.000000000 +0100
+++ /usr/lib/urxvt/perl/matcher.rhonda 2010-03-24 23:57:01.000000000 +0100
@@ -3,13 +3,14 @@
# Author: Tim Pope <rxvt-unicodeNOSPAM@tpope.info>
my $url =
- qr{
+ qr{(?:
(?:https?://|ftp://|news://|mailto:|file://|\bwww\.)
[a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*
(
\([a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*\)| # Allow a pair of matched parentheses
[a-zA-Z0-9\-\@;\/?:&=%\$_+*~] # exclude some trailing characters (heuristic)
)+
+ )|\#[0-9]{4,}
}x;
sub on_user_command {
@@ -145,6 +146,7 @@
my @begin = @-;
my @end = @+;
if (!defined($col) || ($-[0] <= $col && $+[0] >= $col)) {
+ $match =~ s/^#/http:\/\/bugs.debian.org\//;
if ($launcher !~ /\$/) {
return ($launcher,$match);
} else {
The diff is intentionally small so it is clear what is happening here. And it should give ideas for other extensions that one would like to make. I don't consider it though flexible enough to submit it upstream. Enjoy anyway!
A while ago I blogged about squashing release-critical bugs in stable. Yesterday we have reached a big milestone on that area: The amount of release-critical bugs in stable dropped below 1000 (blue graph). This might sound like it's still pretty high but given that we were well over 1600 RC bugs in stable a while ago I consider this quite a success.
This is though no time for rest. There is still way too many RC bugs in stable, there are definitely still a lot of bugs that just aren't affecting stable and thus can be marked as such meaning no upload needs to get done for them. I'm taking a close look at those with higher numbers and most of those seem to be validly affecting stable too so they might require a bit more work than just tagging them.
Thanks to all people who helped on that area, I can just remember a few names and don't want to make anyone else also working on stable to feel singled out, though I want to thank Lucas for tagging his FTBFS rounds with squeeze sid right from the start because the packages obviously have built before due to his regular rebuilds. Thanks to all, but like said, not the time to rest. The green squeeze graph is still around 250 bugs away from us!
![[rss feed]](/pics/logo-xml.png){kind=logo}
![[html by vim]](/pics/logo-vim.png){kind=logo}
![[graphics by gimp]](/pics/logo-gimp.png){kind=logo}
![[generated by wml]](/pics/logo-wml.png){kind=logo}
![[powered by blosxom]](/pics/logo-blosxom.png){kind=logo}