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.
No, my blog isn't dead, and neither is me. It's just that way too many things happened since this year's debconf that got me a bit off tracks. I managed to do daily business like keeping my packages in shape and the backports queue low, and that was mostly it.
No clue if that will change anytime soon, but I guess I would like to keep you updated with an event where you can meet me next week: There will be the Global 2000 Birthday Party going on in the WUK on Thursday 20th, so if you happen to be in Vienna at that time, drop by and enjoy some great bands.
... which brings me to one of the local bands from Vienna: Heinz aus Wien. They are around for well over 10 years now and are still rocking quite well. Here are some examples of their songs, like always:
Ich hab mit Tocotronic Bier getrunken: Quite funny song from their early days, and interestingly, people regularly claim that it was done by a different band ...
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!
This is a very special person. He is a very well known songwriter, at least in German language countries because he sings in German. He was that special kind of person with his lyrics when I was still a kid, and is still around continuing to write his songs in his very own special way. This person is Reinhard Mey, and if you understand German and have missed him so far, you have missed a lot.
The songs that I present to you are special in the way that they are all contained in the special compilation titled Mein Apfelbäumchen. The dedication he wrote for the album is also very special:
Ich glaube, Kinder zu haben ist das aufregendste Abenteuer, das wir erleben können. Es ist der schwerste Beruf und die größte Herausforderung, die ich mir denken kann, und die glücklichste Erfahrung zugleich. Ich bin dankbar dafür! Dies sind die Lieder, die ich bis heute dafür geschrieben habe. Mein Anteil aus dem Erlös dieser Schallplatte gebe ich der Hilfe für krebskranke Kinder.
Rough translation: I believe that having kids is the most exciting adventure that we can undergo. It is the hardest job and the biggest challenge that I can think of, and at the same time the happiest experience. I'm thankful for it! These are the songs that I wrote up to today for it. My part of the revenues of this record go to Help for children with cancer.
So here are the songs:
Mein Apfelbäumchen: The song that gave this compilation its title. Extremely touching, and it manages regularly to wet my eyes... Absolutely lovely.
Keine ruhige Minute: This is actually a live version of the song with a longer introduction that is worth listening to on its own.
Menschenjunges: A thoughtful song about the thoughts when seeing your kid for the first time.
Enjoy! And if you feel like it, support these kind of special people.
Whenever someone asked me about a calendar application, especially for the textmode, I always encouraged them to give pal a try. I always loved the looks of it, the interactive mode is helpful, it has HTML output format to inject the calendar into a webpage, mail output format for a daily reminder cronjob, and other useful features. I even created a file with the Austrian holidays for it which got included in the original project for the benefit of all its users.
If you haven't tried it yet and are looking for a calendar tool with support for very flexible recurring events and categories, this might be a good look.
I am still happy with pal, though someone recently suggested a different tool on IRC, and that was wyrd. From a quick glance it looked promising, so I started to dig into it. My first task was to convert the former mentioned pal file for the Austrian holidays into remind format. remind is the backend for wyrd, and its definition language seems to be extremely powerful. It though took me a while to figure out how to put in Easter date related events into it, the examples weren't really hinting me in the right direction. This is part of what I am using now: REM [trigger(easterdate(current())-47)] +6 TAG noweight MSG Faschingsdienstag %b
The look and view of wyrd is different to pal in several ways. Where the granularity of pal is a pure day view, wyrd scales in hours (or half, quarter thereof). Also, wyrd offers the possibility to color the days differently by busy level. Of course it's possible to exempt tasks from adding weight to a day. pal on the other hand is able to color events differently by category.
Decide yourself what you actually need, test it, and ... enjoy!
Sometimes people will tell you what you should do. Sometimes they will even shout at you for simply asking a question on why they want something done because it isn't clear just from itself. And others likes to jump the boat and join in just for the fun of it...
Gladly, this is MY life, and I choose how much abuse I'm willing to take, especially for a voluntary work that I didn't even enroll for but got put into. Sometimes through my dedication to getting quality into things and seeing that others simply neglect these areas, but they need to get addressed anyway, no matter how little respect is shown for people investing in these boring areas.
The topic of It's MY Life is an old one and thus it is no surprise that a fair amount of songs surrounding it popped up over time. In my previous blog entry I wrote about different interpretations, some responses seem to hint that I wasn't clear enough about that I really meant different interpretations of the same lyrics, not just regular cover versions.
The following set of songs is special in a different sense: It is about the same song title and thus does also cover different bands.
No Doubt: This is the band that Gwen Stefani got known through.
Bon Jovi: No matter what you might think about Bon Jovi, they for sure wrote some pretty touching songs.
Like always, enjoy! And think about how you interact with others. I know that I'm sometimes crossing a line myself too, no one is perfect. What though makes the difference is the willingness to learn, and especially: To excuse. But in the end: It's MY life!
Mostly everything in life boils down to the same troublesome issue: people are reading different things into what they read, and interpret them regularly in a way it wasn't meant to. It seems that in certain areas a culture of interpreting things in a bad way instead of good or asking how they were actually meant has established the rules of (not) working together but rather against each other and around each other. At times I would like to account it to language barriers, or cultural differences, but it happens with people from all areas so that reasoning would be too easy.
Even artists manage to do that, and in that certain area it creates something extremely creative and thoughtful. This blog entry thus contains three songs—and six videos: Two different interpretations of the same lyrics. Maybe this is able to stir some thinking process whether the interpretation that one found for a given situation might be biased or even just looking from the wrong angle.
Imagine (John Lennon vs. A Perfect Circle): It gives me the shivers when thinking about what a different tune and might turn the same lyrics into. The various videos going with this interpretation make me even cry, and since the official video might be blocked in your country I linked one of the private made ones.
Mad World (Tears For Fears vs. Gary Jules): You might not have known the original (Tears For Fears is well known for other songs actually) but only the cover, which was in the soundtrack of Donnie Darko.
Drive (R.E.M. vs. R.E.M.): You read correctly: a band covering itself is rare but it happens. And yes, when I heard the live version back in the years it was a quite enlightening situation.
Enjoy!
One thing I'd like to mention, and that is two cross references to former blog entries. For the first song, James Iha played as guitarist in The Smashing Pumpkins before he joined A Perfect Circle. The second cross reference is with respect to my former blog entry about the Wise Guys: They did also cover Mad World, in the Gary Jules' interpretation but of course in a capella.
There is a whole business around books with worldly wisdoms. They get bought as gifts for friends to cheer them up, they are meant to help one through hard times. I though see a big issue with them:
If you would really need them, you aren't able to adopt them.
If you are able to adopt them, you don't need them.
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.
My brother did invite me to the concert of the Wise Guys, a German acapella group. They are one of those special groups who are able to give a cheering live show and have this special cheek-in-tongue humour in a fair amount of their songs. This is the selection that helps me keeping my mood up though, you are invited to dig further.
Jetzt ist Sommer: This was the first song I heard from them and got me interested to dig further into this band. And yes, it's true, summer is an inner feeling, not something governed by the outer world.
Lass die Sonne scheinen: I have the feeling that this is a sequel to the former song. And it definitely helps too.
Am Ende des Tages: No matter how your day went, what matters most are the people you think of at the end of the day.
Hope you are able to appreciate them as much as I am. At least they are able to cheer me up a fair bit.
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 Debian: Alexander Reichle-Schmehl (thanks for the name!), David Prévot, Francesca Ciceri (thanks for gathering contact information!) and Martin Zobel-Helas (thanks for webserver setting tweaks).
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.
I guess it won't be very many people reading this blog to know the name, even though he was without any doubt one of the biggest entertainers. Lots of movies, his own TV show, and an enormous amount of albums made him well known far outside the borders of Austria, his home country. Last saturday he died in the age of 84, yesterday was his funeral. This is a special dedication to him. Peter, you will be missed.
Die süßesten Früchte (1952): He was still rather young at that time but it already shows his great talent, both in acting and in singing.
Mamma di Mandolin (1956): Another great excerpt from a movie in which he starred.
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.
It's been over a month already since I last suggested a band, this is overdue. Today because of a discussion this band came back into my mind and I want to share it with you: The Chemical Brothers. So without too much further talking here are the songs:
Galvanize: This song got me into love with the band, and it still is a great motivation push.
Hey Boy Hey Girl: An older song of theirs which might also be well known.
The Test: It's not just a nice song but also a terrificly great video!
On 24th of October we've been to the concert of Unheilig. It was actually very touching, even though the sound quality of the venue was disappointing. Here are the common three songs that I usually share about bands that I like to introduce you to:
Mein Stern: Even though it's not my star in those pictures, the song still gives me goose bumps.
Geboren um zu Leben: He wrote this great song for his best friend that isn't anymore.
An deiner Seite: Another truly great of their songs. Let it touch your soul.
I am aware that these songs are all pretty emotional and rather quiet. Unheilig has also a much harder side to them. It's just that my current mood is pretty emotional, that's also the reason for this selection.
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
If I'll make it through this week it's because of these special people in my life. They help me through thick and thin, they believe in me, they are there for me. There is one universal term for them, friends. The term in its real meaning, in its original meaning, not in the perverted sense that sites like Facebook want to make you believe that it's alright to apply to random bystanders. You won't go as far for those as you'd go for your true friends, so don't let them steal away the meaning of the word from you.
As music is one of the most driving force for me and this song makes me wanna cry, this is what I want to send out to my friends who are able to motivate me to keep me going: That's What Friends Are For. And as this song is so special I won't drown it in two more like I usual do, this blog entry goes to my personal section anyway. There is though a second video of a live version of it that in my opinion adds quite something to it, it contains a short interview with Dionne Warwick at the end.
I guess it's time again to push for another band. This time I present you Garbage. I love them, but one has to be careful in what mood one is when listening to them; it's possible that they move you in a direction you don't feel comfortable with at that time.
Bleed Like Me: If you listen closely to the lyrics of the second verse you might get an idea why had to love that song.
The World Is Not Enough: One might argue that a band has made it when they do a James Bond title song. This is it.
Only Happy When It Rains: Probably the best known song from Garbage. Damn fine, great tune and groove for the message it contains.
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!
A while ago I was with my SO at a concert of a band I might cover at a later point. This time I want to cover the support act of that concert: Jerboa. It was a bit weird to see a single person on stage turning some knobs, but he quickly caught both our attention and heart. And he was a charm to talk with afterwards when we bought his CD. He's definitely worth your attention, and if you are able to see him live take the chance for it.
Number 1: The obvious number 1 song in the list. Perfect groovy song, great video too.
Just Another Number: It starts off pretty smooth but then really kicks in. Hard to not headnick along to the song, it is far away from being Just Another Number.
Actually I would have loved to include What if in the songs but unfortunately that one wasn't available so I had to look for a replacement for it.
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.
Alright, get ready for the next round of music links. This time I stumbled upon an old (and still) favorite band of mine while looking for references to Max Headroom: Art of Noise. You most probably have heard the one or the other song from them, they are featured pretty often. Here they are:
Peter Gunn: Also very well known and used often. You have to wait a bit for the music to hook in, there is an intro in the video.
Paranoimia: Third great song you might have heard somewhere already. Absolutely lovely song indeed.
It's really sad to see such great bands to pass away. But it's still the perfect music to have running in the background when hacking along. Highly motivating, great to hum along. Oh, and you might ask, where is the connection to Max Headroom. Here it is, in a special version of Paranoimia featuring Max Headroom!
I got convinced to hold an IRC talk on usage of the Debian BTS in #ubuntu-classroom and thought it might be interested to other children distributions of Debian, too—also for regular Debian users. So feel invited to attend it.
It will be held in #ubuntu-classroom on irc.freenode.net on Thursday, 22nd of July, at 18:00 UTC. For those who have never attended such a session yet, you might want/need to also join #ubuntu-classroom-chat too and raise questions in there, the main channel will be set to moderated.
I will try to cover basic usage like querying the web interface, reporting new bugs and also more deeper handling of bugs, including version tracking issues, and will try to address raised questions as good as possible.
Hope the session will be helpful to some and be able to address some questions like why some bugs aren't getting archived even though they are closed for ages. :) IRC logs will be available for the convenience of those who can't make it.
Working on and for Debian for the whole millennium already it would had been hard to not notice Ubuntu through the times. Given that fixing bugs in the package is in the interest of all involved parties I started to get curious for the packages I maintain in Debian what users of Ubuntu might have filed against them. Given that a fair amount of those actually do also apply to Debian I started to fix them too.
Though, some bug status isn't able to use as an outsider, and given my approach to perfection not wanting to have packages in a bad shape in a release I started to dig a bit further into the procedures and applied to be accepted as a Ubuntu Developer, more specifically as a MOTU, which gives me the possibility to directly ask for syncrequest instead of having to go through a sponsor, or set wontfix status for bugreports in my packages that simply doesn't make sense to get implemented.
Last week I got accepted into that state and I'd like to thank for all the nice and encouraging feedback along the path (including some "What? I thought you were MOTU since ages already??" responses). Let's see how much I really need it, my approach is rather to reduce Ubuntu diffs instead of having to work on them. I though understand that at times close to the releases there can be a need for them, as can be seen in that the package I have to put most effort into (wesnoth-1.8) has a Ubuntu diff in the last lucid release. And because Ubuntu already is in DebianImportFreeze I did a syncrequest for gitolite.
Thanks for accepting me so quickly and rather bureaucratic! And no, Laney, I won't give the talk tomorrow because of this just on my own. ;)
This Monday I was again at concert of Grossstadtgeflüster, and it was again one of the best concerts I've visited. Their new album again has again great songs on it like the former two, and their live performance is truly worth it. Besides they are charming like hell offstage, too. Jen, Raphi and Chriz, I simply love you!
It's hard to choose which songs to put here because there are way too many great ones, so feel free to dig around yourself if you like them:
Weil das morgen noch so ist: Their current single, great video, giving a good impression of their style and the fun they have doing this.
"Today is the greatest day I've ever known,"—this is the line that is spinning around today in my head because of many little things that happened. And it's this time of the month anyway for putting up another band feature into this little blog of mine. So here they are, one of the great bands of the nineties, and like many of them, back after a break again: The Smashing Pumpkins, and these are their featured songs:
Today: The song with the initial mentioned catchphrase. Unfortunately not the official video because in those versions the music is strangely broken. If you want to match it yourself, you can still watch it here: Today (true video, broken music)
Disarm: From the same great album, and one of their songs that gives me goosebumps.
Hope you enjoy this small distraction once a month. I hope I can keep up with it, it's not a question of material, there are too many great bands out there that I'd like to share with others. :)
![[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}